Re: Lowering the ever-growing heap->pd_lower - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Lowering the ever-growing heap->pd_lower
Date
Msg-id CA+TgmoaFM6skfL8C=+sqTkxquG2YqTDYtK-tWSwvWijJHfwnRQ@mail.gmail.com
Whole thread Raw
In response to Re: Lowering the ever-growing heap->pd_lower  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Lowering the ever-growing heap->pd_lower
Re: Lowering the ever-growing heap->pd_lower
List pgsql-hackers
On Tue, Aug 3, 2021 at 8:44 PM Peter Geoghegan <pg@bowt.ie> wrote:
> This time it's quite different: we're truncating the line pointer
> array during pruning. Pruning often occurs opportunistically, during
> regular query processing. In fact I'd say that it's far more common
> than pruning by VACUUM. So the chances of line pointer array
> truncation hurting rather than helping seems higher.

How would it hurt?

It's easy to see the harm caused by not shortening the line pointer
array when it is possible to do so: we're using up space in the page
that could have been made free. It's not so obvious to me what the
downside of shortening it might be. I suppose there is a risk that we
shorten it and get no benefit, or even shorten it and have to lengthen
it again almost immediately. But neither of those things really
matters unless shortening is expensive. If we can piggy-back it on an
existing WAL record, I don't really see what the problem is.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: Added schema level support for publication.
Next
From: John Naylor
Date:
Subject: RFC: Improve CPU cache locality of syscache searches