On Fri, Jan 26, 2018 at 10:56:06AM +0300, Konstantin Knizhnik wrote: > >>Yeh, I suspected that just disabling autovacuum was not enough. > >>I heard (but do no know too much) about microvacuum and hot updates. > >>This is why I was a little bit surprised when me test didn't show lost of > >>updated versions. > >>May be it is because of vacuum_defer_cleanup_age. > >Well vacuum and single-page pruning do 3 things: > > > >1. remove expired updated rows > >2. remove deleted row > >3. remove rows from aborted transactions > > > >While time travel doesn't want #1 and #2, it probably wants #3. > > > Rows of aborted transactions are in any case excluded by visibility checks. > Definitely skipping them costs some time, so large percent of aborted > transactions may affect query speed. > But query speed is reduced in any case if in order to support time travel we > prohibit or postpone vacuum. > > What is the expected relation of committed and aborted transactions? I > expected that it should be much bigger than one (especially if we take in > account > only read-write transaction which has really updated database). In this case > number of versions created by aborted transaction should be much smaller > than number of versions created by updated/delete of successful > transactions. So them should not have significant impact on performance.
Uh, I think the big question is whether we are ready to agreed that a time-travel database will _never_ have aborted rows removed. The aborted rows are clearly useless for time travel, so the question is whether we ever want to remove them. I would think at some point we do. Also, I am not sure we have any statistics on how many aborted rows are in each table. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
