Howard Chu hyc@symas.com schrieb am 12.08.2019 um 18:08 in Nachricht
c2b25d9b-1314-1f6f-6635-d0c1167f35fa@symas.com:
Sam Dave wrote:
Hi,
Are transaction commits always fast (almost instantaneous) operations
compared to the read or write operations within it? Is it possible for say an
mdb_cursor_get or mdb_put to be faster than a subsequent mdb_txn_commit, and
if so under what circumstances can that happen?
This is relevant info for UI applications showing a progress indicator. If
an mdb_txn_commit is always fast, we can rely on the _get/_put count to calculate the
percentage.
Generally no, a txn_commit should take time proportional to the number of pages that were dirtied in the transaction. And that number depends on the number of puts/dels that were performed in the transaction.
gets don't dirty any pages, so they are irrelevant for commit speed.
I think it's obvious for any DB system: As a commit has to flush all changes to permanent storage, while plain writes may loinger around in some writeback buffers, commit is usually the slow thing. Exceptions proving the rule: If you wait a long time until commit after write, the buffery may have been flushed in the meantime and commit can be fast. Alse write can be slower than commit if the system runs out of dirty-able buffers (and thus has to wait for dirty buffers to be flushed).
As for a progress bar: I'd update it after a commit: If you want it somewhat smooth, make smaller transactions. If you display uncommitted changes, the progress most likely will be "jumpy"...
Regards, Ulrich
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/