Re: Eager page freeze criteria clarification

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Eager page freeze criteria clarification
Дата
Msg-id CAH2-Wzm-bk+ywCvkNYENpBhW45+s8QDPeUukS3epEYb8EUe46A@mail.gmail.com
обсуждение исходный текст
Ответ на Eager page freeze criteria clarification  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
On Wed, Sep 27, 2023 at 11:36 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> One big sticking point for me (brought up elsewhere in this thread, but,
> AFAICT never resolved) is that it seems like the fact that we mark pages
> all-visible even when not freezing them means that no matter what
> heuristic we use, we won't have the opportunity to freeze the pages we
> most want to freeze.

I think of it as being a bit like an absorbing state from a Markov
chain. It's a perfect recipe for weird path dependent behavior, which
seems to make your task just about impossible. It literally makes
vacuuming more frequently lead to less useful work being performed! It
does so *reliably*, in the simplest of cases.

Ideally, you'd be designing an algorithm for a system where we could
expect to get approximately the desired outcome whenever we have
approximately the right idea. A system where mistakes tend to "cancel
each other out" over time. As long as you have "set all-visible but
don't freeze" behavior as your starting point, then ISTM that your
algorithm almost has to make no mistakes at all to really improve on
what we have right now. As things stand, when your algorithm decides
to not freeze (for pages that are still set all-visible in the VM),
you really can't afford to be wrong. (I think that you get this
already, but it's a point worth emphasizing.)

--
Peter Geoghegan



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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Eager page freeze criteria clarification
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Annoying build warnings from latest Apple toolchain