Victor Baybekov wrote:
Working with overflow pages directly via pointers outside write transactions works great
and it helps that they do not move "by design" in current versions as
discussed in this thread.
I have two related scenarios that will give a substantial performance boost in my case.
/The first one/ is updating a value in-place via pointer from aborted write transaction.
1) use MDB_WRITEMAP,
2) from **write** transaction find a record (which is small and not in an overflow
3) modify a part of it's value (for duplicates this part is not used in the compare
function) directly via the MDB_VAL data pointer (e.g. interlocked_increment
4) and **abort** the transaction,
then readers see the updated value via normal read transactions later. Since I do the
direct updates from inside a write transaction all other writers should be
locked until I exit the transaction (abort in this case), and no pages should move since
the transaction is aborted. Is this correct? Does this work "by design"
or "by accident" currently?
By accident. Note that LMDB 1.0 supports page checksums, and what you're doing here
will break those checksums.
/The second one/ is about updating values in-place from read
transactions. If I
Updating any value in a read transaction is ludicrous.
Basically you're abusing MDB_WRITEMAP, whose only purpose is to (potentially)
normal write transactions. I've no interest in even speculating on intentional misuse
of the API.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/