Re: Lowering the ever-growing heap->pd_lower

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Lowering the ever-growing heap->pd_lower
Дата
Msg-id CA+TgmoaFM6skfL8C=+sqTkxquG2YqTDYtK-tWSwvWijJHfwnRQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Lowering the ever-growing heap->pd_lower  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Lowering the ever-growing heap->pd_lower  (Peter Geoghegan <pg@bowt.ie>)
Re: Lowering the ever-growing heap->pd_lower  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: "tanghy.fnst@fujitsu.com"
Дата:
Сообщение: RE: Added schema level support for publication.
Следующее
От: John Naylor
Дата:
Сообщение: RFC: Improve CPU cache locality of syscache searches