https://bugs.openldap.org/show_bug.cgi?id=10220
Issue ID: 10220 Summary: Feature Request: new option for append-only write transaction Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs@openldap.org Reporter: xhtang518@gmail.com Target Milestone: ---
My project uses LMDB to store values larger than 100KB, and rarely delete values. So I can afford wasting some space on free pages, then LMDB can reduce 4KB-write operations and improve write performance when committing write transactions.
I suppose this feature is not hard to implement: just pretend the free-list is empty in this transaction if the new option is present. Is this feature reasonable?
https://bugs.openldap.org/show_bug.cgi?id=10220
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Howard Chu hyc@openldap.org --- No, nor is it necessary. If you want to make LMDB ignore the freelist, just keep a read transaction open all the time.
https://bugs.openldap.org/show_bug.cgi?id=10220
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=10220
--- Comment #2 from Xianghao Tang xhtang518@gmail.com --- (In reply to Howard Chu from comment #1)
No, nor is it necessary. If you want to make LMDB ignore the freelist, just keep a read transaction open all the time.
An active read transaction can prevent pages already in DB from being reused, but futher write commits will create new tree node pages, then I need to reopen the read transaction every time, which sounds a little weird.
Besides, append-only write is friendly to MDB_NOLOCK in single writer scenario, but this workaround requires the writer to check lock.mdb, resulting in extra I/O cost.