On Wed, Sep 27, 2023 at 5:42 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> On Wed, Sep 27, 2023 at 5:27 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > What about my idea of holding back when some tuples are already frozen
> > from before? Admittedly that's still a fairly raw idea, but something
> > along those lines seems promising.
>
> Originally, when you proposed this, the idea was to avoid freezing a
> page that has some tuples already frozen because that would mean we
> have frozen it and it was unfrozen after.
Right.
> But, today, I was thinking about what heuristics to combine with one
> that considers the average amount of time pages in a table spend
> frozen [1], and I think it might be interesting to use the "some
> tuples on the page are frozen" test in the opposite way than it was
> originally proposed.
>
> Take a case where you insert a row and then update it once and repeat
> forever. Let's say you freeze the page before you've filled it up,
> and, on the next update, the page is unfrozen. Most of the tuples on
> the page will still be frozen. The next time the page is vacuumed, the
> fact that the page has a lot of frozen tuples actually means that it
> is probably worth freezing the remaining few tuples and marking the
> page frozen.
Assuming that you can get away with not writing an FPI, yeah,
probably. Otherwise, maybe, less clear.
> Basically, I'm wondering if we can use the page-is-partially-frozen
> test to catch cases where we are willing to freeze a page a couple of
> times to make sure it gets frozen.
That doesn't seem like the opposite of my suggestion (except maybe in
a mechanical sort of way). To me this sounds like a refinement of the
same idea (not surprising that it would need to be refined).
You seem to be suggesting that we would freeze if either no tuples
were frozen at all, or if almost all tuples were already frozen -- but
not if the page was "somewhere in between". I think I see where you're
going with that.
--
Peter Geoghegan