Re: Pruning never visible changes

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

In response to

Responses

Browse pgsql-hackers by date

  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