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
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 |