[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Antw: Re: Transaction commit speed
>>> 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/