From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lowering the ever-growing heap->pd_lower |
Date: | 2022-04-07 22:43:05 |
Message-ID: | CAH2-Wz=wxxXQ=avcYojhOYUUPTNZcsHECBf_kue9dYZFAEzehw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 4, 2022 at 7:24 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I am sympathetic to the idea that giving the system a more accurate
> picture of how much free space is available on each heap page is an
> intrinsic good. This might help us in a few different areas. For
> example, the FSM cares about relatively small differences in available
> free space *among* heap pages that are "in competition" in
> RelationGetBufferForTuple(). Plus we have a heuristic based on
> PageGetHeapFreeSpace() in heap_page_prune_opt() to consider.
Pushed a slightly revised version of this just now. Differences:
* Rewrote the comments, and adjusted related comments in vacuumlazy.c.
Mostly just made them shorter.
* I eventually decided that it was fine to just accept the issue with
maxoff in lazy_scan_prune (the pruning path used by VACUUM).
There seemed to be no need to reestablish a maxoff for the page here
following further reflection. I changed my mind.
Setting reclaimed line pointer array space to a pattern of 0x7F bytes
wasn't adding much here. Pruning either runs in VACUUM, or
opportunistically. When it runs in VACUUM things are highly
constrained already. Opportunistic pruning for heap_page_prune_opt()
callers doesn't even require that the caller start out with a buffer
lock. Pruning only goes ahead when we successfully acquire a cleanup
lock -- so callers can't be relying on maxoff not changing.
* Didn't keep the changes to PageTruncateLinePointerArray().
There is at least no reason to tie this question about VACUUM to how
pruning behaves. I still see some small value in avoiding creating a
new path that allows PageIsEmpty() pages to come into existence in a
new way, which is no less true with the patch I pushed.
Thanks
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-04-07 23:01:01 | Re: Lowering the ever-growing heap->pd_lower |
Previous Message | David Rowley | 2022-04-07 22:40:37 | Re: Window Function "Run Conditions" |