From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
Date: | 2024-01-09 05:56:34 |
Message-ID: | ZZzgEteeBHV8-VDF@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 08, 2024 at 03:50:47PM -0500, Robert Haas wrote:
> Hmm, interesting. I haven't had time to study this fully today, but I
> think 0001 looks fine and could just be committed. Hooray for killing
> useless variables with dumb names.
I've been looking at 0001 a couple of weeks ago and thought that it
was fine because there's only one caller of lazy_scan_prune() and one
caller of lazy_scan_noprune() so all the code paths were covered.
+ /* rel truncation is unsafe */
+ if (hastup)
+ vacrel->nonempty_pages = blkno + 1;
Except for this comment that I found misleading because this is not
about the fact that truncation is unsafe, it's about correctly
tracking the the last block where we have tuples to ensure a correct
truncation. Perhaps this could just reuse "Remember the location of
the last page with nonremovable tuples"? If people object to that,
feel free.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-01-09 06:08:37 | Re: Removing unneeded self joins |
Previous Message | Hayato Kuroda (Fujitsu) | 2024-01-09 05:49:26 | RE: Random pg_upgrade test failure on drongo |