Re: Eager page freeze criteria clarification - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Eager page freeze criteria clarification
Date
Msg-id 20230926151943.gn4itbeckwfpbbsw@alap3.anarazel.de
Whole thread Raw
In response to Re: Eager page freeze criteria clarification  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Eager page freeze criteria clarification
List pgsql-hackers
Hi,

On 2023-09-25 14:16:46 -0700, Peter Geoghegan wrote:
> On Mon, Sep 25, 2023 at 11:45 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I'm surprised that there hasn't been any discussion of the absolute
> amount of system-wide freeze debt on this thread. If 90% of the pages
> in the entire database are frozen, it'll generally be okay if we make
> the wrong call by freezing lazily when we shouldn't. This is doubly
> true within small to medium sized tables, where the cost of catching
> up on freezing cannot ever be too bad (concentrations of unfrozen
> pages in one big table are what really hurt users).

I generally agree with the idea of using "freeze debt" as an input - IIRC I
proposed using the number of frozen pages vs number of pages as the input to
the heuristic in one of the other threads about the topic a while back. I also
think we should read a portion of all-visible-but-not-frozen pages during
non-aggressive vacuums to manage the freeze debt.

However, I'm not at all convinced doing this on a system wide level is a good
idea. Databases do often contain multiple types of workloads at the same
time. E.g., we want to freeze aggressively in a database that has the bulk of
its size in archival partitions but has lots of unfrozen data in an active
partition. And databases have often loads of data that's going to change
frequently / isn't long lived, and we don't want to super aggressively freeze
that, just because it's a large portion of the data.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: pg_resetwal tests, logging, and docs update
Next
From: Robert Haas
Date:
Subject: Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }