Re: Add 64-bit XIDs into PostgreSQL 15
От | Peter Eisentraut |
---|---|
Тема | Re: Add 64-bit XIDs into PostgreSQL 15 |
Дата | |
Msg-id | 76c9eaf2-a924-4df1-8cdc-c6be7d5cf7ac@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Add 64-bit XIDs into PostgreSQL 15 (Aleksander Alekseev <aleksander@timescale.com>) |
Ответы |
Re: Add 64-bit XIDs into PostgreSQL 15
Re: Add 64-bit XIDs into PostgreSQL 15 |
Список | pgsql-hackers |
On 23.07.24 11:13, Aleksander Alekseev wrote: >> Here is the fix. It can be tested like this: >> [...] > > PFA the rebased patchset. 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? 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. Your 0004 patch adds support for 64-bit GUCs but doesn't actually convert any existing GUCs to use that. (Unlike the reloptions, which your patch coverts.) And so there is no documentation about these questions.
В списке pgsql-hackers по дате отправления: