On 25/07/2024 13:19, Peter Eisentraut wrote:
I'm wondering about the 64-bit GUCs.
At first, it makes sense that if there are settings that are counted in
terms of transactions, and transaction numbers are 64-bit integers, then
those settings should accept 64-bit integers.
But what is the purpose and effect of setting those parameters to such
huge numbers? For example, what is the usability of being able to set
vacuum_failsafe_age = 500000000000
I think in the world of 32-bit transaction IDs, you can intuitively
interpret most of these "transaction age" settings as "percent toward
disaster". For example,
vacuum_freeze_table_age = 150000000
is 7% toward disaster, and
vacuum_failsafe_age = 1600000000
is 75% toward disaster.
However, if there is no more disaster threshold at 2^31, what is the
guidance for setting these? Or more radically, why even run
transaction-count-based vacuum at all?
To allow the CLOG to be truncated. There's no disaster anymore, but
without freezing, the clog will grow indefinitely.
Conversely, if there is still some threshold (not disaster, but
efficiency or something else), would it still be useful to keep these
settings well below 2^31? In which case, we might not need 64-bit GUCs.
Yeah, I don't think it's critical. It makes sense to switch to 64 bit
GUCs, so that you can make those settings higher, but it's not critical
or strictly required for the rest of the work.
Another approach is to make the GUCs to mean "thousands of XIDs",
similar to how many of our memory settings are in kB rather than bytes.
that might be a super confusing change for existing settings though.
--
Heikki Linnakangas
Neon (https://neon.tech)
