From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: New strategies for freezing, advancing relfrozenxid early |
Date: | 2022-12-31 19:46:15 |
Message-ID: | ebc857107fe3edd422ef8a65191ca4a8da568b9b.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2022-12-30 at 16:58 -0800, Peter Geoghegan wrote:
> Following the path of freezing a page is *always* valid, by
> definition. Including when there are zero freeze plans to execute, or
> even zero tuples to examine in the first place -- we'll at least be
> able to perform nominal freezing, no matter what.
This is a much clearer description, in my opinion. Do you think this is
already reflected in the comments (and I missed it)?
Perhaps the comment in the "if (tuples_frozen == 0)" branch could be
something more like:
"We have no freeze plans to execute, so there's no cost to following
the freeze path. This is important in the case where the page is
entirely frozen already, so that the page will be marked as such in the
VM."
I'm not even sure we really want a new concept of "nominal freezing". I
think you are right to just call it a degenerate case where it can be
interpreted as either freezing zero things or not freezing; and the
former is convenient for us because we want to follow that code path.
That would be another good way of writing the comment, in my opinion.
Of course, I'm sure there are some nuances that I'm still missing.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-12-31 20:45:26 | Re: New strategies for freezing, advancing relfrozenxid early |
Previous Message | Ankit Kumar Pandey | 2022-12-31 19:43:24 | [PATCH] Add overlaps geometric operators that ignore point overlaps |