Re: PostgreSQL and a Catch-22 Issue related to dead rows - Mailing list pgsql-performance

From Tom Lane
Subject Re: PostgreSQL and a Catch-22 Issue related to dead rows
Date
Msg-id 3908773.1733760455@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL and a Catch-22 Issue related to dead rows  (Christophe Pettus <xof@thebuild.com>)
Responses Re: PostgreSQL and a Catch-22 Issue related to dead rows
Re: PostgreSQL and a Catch-22 Issue related to dead rows
List pgsql-performance
Christophe Pettus <xof@thebuild.com> writes:
>> On Dec 9, 2024, at 03:02, Lars Aksel Opsahl <Lars.Opsahl@nibio.no> wrote:
>> If there were a way to remove dead rows without requiring a commit from totally unrelated jobs, it would be much
easier.

> (Strictly speaking, the rows you are describing are not "dead," in that they are still visible to some transaction.)

We do only very coarse-grained analysis of whether a row is "dead".
In principle, if vacuum had access to all the live snapshots of
all sessions, it could realize that a row really is dead even though
it's later than the current global xmin horizon.  But discovering that
would be quite difficult and therefore expensive.  Notably, sessions
would have to expose far more of their snapshot state than they do
today, and there would have to be interlocks to allow other sessions
to inspect that state safely, and that'd probably put us into much the
same sort of too-many-lock-conflicts problem that the OP has already.

I don't think there's any free lunch here.  Maybe there's some
other compromise between amount-of-state-exposed versus
dead-row-discoverability, but finding a better way would take
a great deal of creative effort and testing.

            regards, tom lane



pgsql-performance by date:

Previous
From: Christophe Pettus
Date:
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
Next
From: Eric Schwarzenbach
Date:
Subject: can a blocked transaction affect the performance of one that is blocking it?