Re: New strategies for freezing, advancing relfrozenxid early

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: New strategies for freezing, advancing relfrozenxid early
Дата
Msg-id CAH2-WzkX7DSjFDJW8NgV5nNg+9MY5VtifDQto9zrtF_zb6BmXQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New strategies for freezing, advancing relfrozenxid early  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers
On Thu, Jan 26, 2023 at 11:26 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> Could someone explain to me why we don't currently (optionally)
> include the functionality of page freezing in the PRUNE records? I
> think they're quite closely related (in that they both execute in
> VACUUM and are required for long-term system stability), and are even
> more related now that we have opportunistic page-level freezing. I
> think adding a "freeze this page as well"-flag in PRUNE records would
> go a long way to reducing the WAL overhead of aggressive and more
> opportunistic freezing.

Yeah, we've talked about doing that in the past year. It's quite
possible. It would make quite a lot of sense, because the actual
overhead of the WAL record for freezing tends to come from the generic
WAL record header stuff itself. If there was only one record for both,
then you'd only need to include the relfilenode and block number (and
so on) once.

It would be tricky to handle Multis, so what you'd probably do is just
freezing xmin, and possibly aborted and locker XIDs in xmax. So you
wouldn't completely get rid of the main freeze record, but would be
able to avoid it in many important cases.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Reid Thompson
Дата:
Сообщение: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Следующее
От: Tomas Vondra
Дата:
Сообщение: lockup in parallel hash join on dikkop (freebsd 14.0-current)