From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pruning never visible changes |
Date: | 2022-09-16 17:37:34 |
Message-ID: | 3843084.1663349854@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> writes:
> On Fri, 16 Sept 2022 at 15:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> You cannot
>> do that, at least not without checking that the originating
>> transaction has no snapshots that could see the older row version.
> I'm saying this is possible only AFTER the end of the originating
> xact, so there are no issues with additional snapshots.
I see, so the point is just that we can prune even if the originating
xact hasn't yet passed the global xmin horizon. I agree that's safe,
but will it fire often enough to be worth the trouble? Also, why
does it need to be restricted to certain shapes of HOT chains ---
that is, why can't we do exactly what we'd do if the xact *were*
past the xmin horizon?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sergei Kornilov | 2022-09-16 18:25:13 | Re:pg_stat_statements and "IN" conditions |
Previous Message | Simon Riggs | 2022-09-16 16:56:42 | Re: Pruning never visible changes |