Re: Eager page freeze criteria clarification

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Eager page freeze criteria clarification
Date: 2023-08-28 16:48:13
Message-ID: CAH2-Wzm9DAzr_fsMdb5ef_VCrOFF6QHkkLDzk_bomTsMGFZrpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 28, 2023 at 7:00 AM Melanie Plageman
<melanieplageman(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema 2023-08-28 16:51:02 Re: Support prepared statement invalidation when result types change
Previous Message Jelte Fennema 2023-08-28 16:47:59 Re: Support prepared statement invalidation when result types change