From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: Eager page freeze criteria clarification |
Date: | 2023-10-12 14:26:28 |
Message-ID: | CA+TgmoZ0f3xqU+WBcdLfpu6ieW5JyVQO14ysTZ1edxq=O4fhsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for these notes.
On Wed, Oct 11, 2023 at 8:43 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> - We also discussed an idea by Robert to track the number of times we need to
> dirty a page when unfreezing and to compare that to the number of pages
> dirtied overall (IIRC), but I don't think we really came to a conclusion
> around that - and I didn't write down anything so this is purely from
> memory.
See http://postgr.es/m/CA+TgmoYcWisxLBL-pXu13OevThLOXm20oJqjNRZtKkhXsY92XA@mail.gmail.com
for my on-list discussion of this.
> - Attributing "unfreezes" to specific vacuums would be powerful:
>
> - "Number of pages frozen during vacuum" and "Number of pages unfrozen that
> were frozen during the same vacuum" provides numerator / denominator for
> an "error rate"
I want to highlight the denominator issue here. I think we all have
the intuition that if we count the number of times that a
recently-frozen page gets unfrozen, and that's a big number, that's
bad, and a sign that we need to freeze less aggressively. But a lot of
the struggle has been around answering the question "big compared to
what". A lot of the obvious candidates fail to behave nicely in corner
cases, as discussed in the above email. I think this is one of the
better candidates so far proposed, possibly the best.
> - This approach could provide "goals" for opportunistic freezing in a
> somewhat understandable way. E.g. aiming to rarely unfreeze data that has
> been frozen within 1h/1d/...
This strikes me as another important point. Making the behavior
understandable to users is going to be important, because sometimes
whatever system we might craft will misbehave, and then people are
going to need to be able to understand why it's misbehaving and how to
tune/fix it so it works.
> Around this point my laptop unfortunately ran out of battery. Possibly the
> attendees of this mini summit also ran out of steam (and tea).
When the tea is gone, there's little point in continuing.
> I likely mangled this substantially, both when taking notes during the lively
> discussion, and when revising them to make them a bit more readable.
I think it's quite a good summary, actually. Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-10-12 14:34:35 | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
Previous Message | David Steele | 2023-10-12 14:25:45 | Re: The danger of deleting backup_label |