From: Hannu Krosing
To: Greg Sabino Mullane
Cc: Lars Aksel Opsahl ; Tom Lane ;
Christophe Pettus ; pgsql-performance@lists.postgresql.org
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
If there are unremovable rows it usually also means tha
If there are unremovable rows it usually also means that index-only scan
degrades to index-scan-with-visibility-checks-in-tables.
I think the ask is to be able to remove the recently dead rows that are not
visible in any current snapshot and can never become visible to any future
snapshot,
Somethi
Thanks for that link; seeing actual queries is a big help. One thing to try
is to get some index-only scans to run. Regular indexes need to consult the
heap (main table) for visibility information, and a bloated table can make
that consultation expensive.
For example, an index like this should wor
Sent: Tuesday, December 10, 2024 2:03 PM
To: Lars Aksel Opsahl
Cc: Tom Lane ; Christophe Pettus ;
pgsql-performance@lists.postgresql.org
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
On Tue, Dec 10, 2024 at 3:55 AM Lars Aksel Opsahl
mailto:l
On Tue, Dec 10, 2024 at 3:55 AM Lars Aksel Opsahl
wrote:
> Is it difficult to add parameter like force-dead-rows-removal that we send
> to the vacuum job that will remove this rows like this ?
>
> I'm still not sure what the ask here is - complete literal removal of the
dead rows? That's not how
Yes.
Also, are you sure you mean deadlock ? It sounded like this is just a
simple lock conflict and not a deadlock.
The first transaction could be blocked on something else (even tho it's not
ally short and quick ).
Lock requests are in a queue
On Mon, 9 Dec 2024, 21:16 Eric Schwarzenbach,
wrot
From: Tom Lane
Sent: Monday, December 9, 2024 5:07 PM
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 la
