|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>|
|Cc:||Greg Stark <stark(at)mit(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: AS OF queries|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
> 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.
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
|Next Message||Robert Haas||2018-01-26 13:29:26||Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory|
|Previous Message||Antonin Houska||2018-01-26 13:04:26||Re: [HACKERS] WIP: Aggregation push-down|