Re: Eager page freeze criteria clarification

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

On Thu, Sep 7, 2023 at 10:46 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> You mean the current heuristic or some new heuristic we're coming up with in
> this thread? If the former, unfortunately I think the current heuristic often
> won't trigger in cases where freezing would be fine, e.g. on an insert-mostly
> (or hot pruned) workload with some read accesses. If the tuples are already
> hint-bitted, there's no FPI during heap_page_prune(), and thus we don't freeze
> - even though we *do* subsequently trigger an FPI, while setting all-visible.

It's obviously not adequate, or anything like that. I didn't say that it was.

I've heard plenty of complaints about freezing and antiwraparound
autovacuuming, and basically no complaints about the cost of FPIs due
to checksums (apparently Robert wasn't aware of the problem, at least
not as it relates to VACUUM setting the VM). This is true even though
one might expect it to be the other way around, based on simple
analysis using pg_waldump.

There are probably lots of reasons for why that is, but the biggest
reason is likely that users just really hate huge balloon payments for
things like freezing. It's just about the worst thing about the
system.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-09-08 06:20:37 Re: persist logical slots to disk during shutdown checkpoint
Previous Message Richard Guo 2023-09-08 06:08:34 Re: A minor adjustment to get_cheapest_path_for_pathkeys