ISAR/libmdbx
3
0
Fork 0
mirror of https://github.com/isar/libmdbx.git synced 2024-10-29 23:19:20 +08:00
Code Issues Packages Projects Releases Wiki Activity

mdbx: minor refine API description.

Browse Source 
Change-Id: If5615ebff66fe6928d24d22e1300fdf59361527d
This commit is contained in:
Leonid Yuriev 2020-01-02 12:14:17 +03:00
parent 0a487d0b9e
commit f3a95fe26b
1 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
mdbx.h
View File

@ -55,10 +55,10 @@
* transaction logs or append-only data writes, MDBX requires no maintenance
* during operation. Both write-ahead loggers and append-only databases require
* periodic checkpointing and/or compaction of their log or database files
* otherwise they grow without bound. MDBX tracks free pages within the database
* and re-uses them for new write operations, so the database size does not grow
* without bound in normal use. It is worth noting that the "next" version
* libmdbx (MithrilDB) will solve this problem.
* otherwise they grow without bound. MDBX tracks retired/freed pages within the
* database and re-uses them for new write operations, so the database size does
* not grow without bound in normal use. It is worth noting that the "next"
* version libmdbx (MithrilDB) will solve this problem.
*
* The memory map can be used as a read-only or read-write map. It is read-only
* by default as this provides total immunity to corruption. Using read-write
@ -403,17 +403,16 @@
* the lock was restored - we have to wait until such a process releases the
* database, and so on.
*
* - Avoid long-lived transactions, especially in the scenarios with a high
* rate of write transactions. Read transactions prevent reuse of pages
* freed by newer write transactions, thus the database can grow quickly.
* Write transactions prevent other write transactions, since writes are
* serialized.
* - Avoid long-lived read transactions, especially in the scenarios with a
* high rate of write transactions. Long-lived read transactions prevents
* recycling pages retired/freed by newer write transactions, thus the
* database can grow quickly.
*
* Understanding the problem of long-lived read transactions requires some
* explanation, but can be difficult for quick perception. So is is
* reasonable to simplify this as follows:
* 1. Garbage collection problem exists in all databases one way or
* another, e.g. VACUUM in PostgreSQL. But in _libmdbx_ it's even more
* another, e.g. VACUUM in PostgreSQL. But in MDBX it's even more
* discernible because of high transaction rate and intentional
* internals simplification in favor of performance.
*