On 19.06.2024 21:06, Peter Geoghegan wrote:
> On Wed, Jun 19, 2024 at 1:39 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> FWIW I don't think HEAP_XMAX_INVALID as purely a hint.
>> HEAP_XMAX_COMMITTED is a hint, for sure, as is HEAP_XMIN_COMMITTED on
>> its own; but as far as I recall, the INVALID flags must persist once
>> set.
>
> Seems we disagree on some pretty fundamental things in this area, then.
To resolve this situation seems it is necessary to agree on what
is a "hint bit" exactly means and how to use it.
For example, in this way:
1) Definition. The "hint bit" if it is set represents presence of the property of some object (e.g. tuple).
The value of a hint bit can be derived again at any time. So it is acceptable for a hint
bit to be lost during some operations.
2) Purpose. (It has already been defined by Yura Sokolov in one of the previous letters)
Some work (e.g CPU + mem usage) must be done to check the property of some object.
Checking the hint bit, if it is set, saves this work.
So the purpose of the hint bit is optimization.
3) Use. By default code that needs to check some property of the object
must firstly check the corresponding hint bit. If hint is set, determine that the property
is present. If hint is not set, do the work to check this property of the object and set
hint bit if that property is present.
Also, non-standard behavior is allowed, when the hint bit is ignored and the work on property
check will be performed unconditionally for some reasons. In this case the code must contain
a comment with an explanation of this reason.
And maybe for clarity, explicitly say that some bit is a hint right in its definition?
For instance, use HEAP_XMIN_COMMITTED_HINT instead of HEAP_XMIN_COMMITTED.
Remarks and concerns are gratefully welcome.
With the best regards,
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
