Re: Eager page freeze criteria clarification

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Eager page freeze criteria clarification
Дата
Msg-id CAH2-Wzm9DAzr_fsMdb5ef_VCrOFF6QHkkLDzk_bomTsMGFZrpQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Eager page freeze criteria clarification  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
On Mon, Aug 28, 2023 at 7:00 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> I believe that there are two goals that should dictate whether or not we
> should perform opportunistic freezing:
>
>   1. Is it cheap? For example, if the buffer is already dirty, then no
>   write amplification occurs, since it must be written out anyway.
>   Freezing is also less expensive if we can do it without emitting an
>   FPI.
>
>   2. Will it be effective; that is, will it stay frozen?
>   Opportunistically freezing a page that will immediately be modified is
>   a waste.
>
> The current heuristic on master meets neither of these goals: it freezes
> a page if pruning emitted an FPI for it. This doesn't evaluate whether
> or not freezing itself would be cheap, but rather attempts to hide
> freezing behind an expensive operation.

The goal is to minimize the number of FPIs over time, in general.
That's hardly the same thing as hiding the cost.

> Furthermore, it often fails to
> freeze cold data and may indiscriminately freeze hot data.

You need to account for the cost of not freezing, too. Controlling the
overall freeze debt at the level of whole tables (and the level of the
whole system) is very important. In fact it's probably the single most
important thing. A good model might end up increasing the cost of
freezing on a simple quantitative basis, while making life much better
overall. Huge balloon payments for freezing are currently a huge
problem.

Performance stability might come with a cost in some cases. There
isn't necessarily anything wrong with that at all.

--
Peter Geoghegan



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

Предыдущее
От: Jelte Fennema
Дата:
Сообщение: Re: Support prepared statement invalidation when result types change
Следующее
От: Jelte Fennema
Дата:
Сообщение: Re: Support prepared statement invalidation when result types change