Re: Eager page freeze criteria clarification

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, 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-28 00:20:22
Message-ID: CAAKRu_Z+ioDFDSbOqjawzBYu9MWW89+dMyCZdC68WWk1gU0LOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 27, 2023 at 7:39 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Wed, Sep 27, 2023 at 4:09 PM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> > At the risk of seeming too execution-focused, I want to try and get more
> > specific. Here is a description of an example implementation to test my
> > understanding:
> >
> > In table-level stats, save two numbers: younger_than_cpt/older_than_cpt
> > storing the number of instances of unfreezing a page which is either
> > younger or older than the start of the most recent checkpoint at the
> > time of its unfreezing
>
> Can you define "unfreeze"? I don't know if this newly invented term
> refers to unsetting a page that was marked all-frozen following (say)
> an UPDATE, or if it refers to choosing to not freeze when the option
> was available (in the sense that it was possible to do it and fully
> mark the page all-frozen in the VM). Or something else.

By "unfreeze", I mean unsetting a page all frozen in the visibility
map when modifying the page for the first time after it was last
frozen.

I would probably call choosing not to freeze when the option is
available "no freeze". I have been thinking of what to call it because
I want to add some developer stats for myself indicating why a page
that was freezable was not frozen.

> I also find the term "opportunistic freezing" confusing. What's
> opportunistic about it? It seems as if the term has been used as a
> synonym of "freezing not triggered by min_freeze_age" on this thread,
> or "freezing that is partly conditioned on setting the page all-frozen
> in the VM", but I'm not even sure of that.

By "opportunistic freezing", I refer to freezing not triggered by
min_freeze_age. Though we only do so now if the page could be set
all-frozen, that is not a requirement for use of the term, IMO. I
assume that we are not considering changing any behavior related to
freezing when a tuple is older than freeze_min_age, so I think of that
freezing as "required". And any freezing of newer tuples is
opportunistic.

> The choice to freeze or not freeze pretty much always relies on
> guesswork about what'll happen to the page in the future, no?
> Obviously we wouldn't even apply the FPI trigger criteria if we could
> somehow easily determine that it won't work out (to some degree that's
> what conditioning it on being able to set the all-frozen VM bit
> actually does).

I suppose you are thinking of "opportunistic" as freezing whenever we
aren't certain it is the right thing to do simply because we have the
opportunity to do it? If so, I'm not sure we need that distinction
currently. It seems more useful in a narrative context as a way of
characterizing a situation than it does when categorizing different
behaviors.

I want a way to express "freeze when freeze min age doesn't require it"

- Melanie

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2023-09-28 00:30:36 Re: [PGdocs] fix description for handling pf non-ASCII characters
Previous Message David Rowley 2023-09-27 23:49:47 Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()