Hi,
> I seriously doubt that _age values exceeding INT32_MAX would be
> useful, even in the still-extremely-doubtful situation that we
> get to true 64-bit XIDs. But if you think we must have that,
> we could still use float8 GUCs for them. float8 is exact up
> to 2^53 (given IEEE math), and you
On Thu, Sep 26, 2024 at 12:30 PM wenhui qiu wrote:
> I think we need int64 GUCs, due to these parameters（
> autovacuum_freeze_table_age, autovacuum_freeze_max_age,When a table age is
> greater than any of these parameters an aggressive vacuum will be performed,
> When we implementing xid
Alexander Korotkov writes:
> Do you think we don't need int64 GUCs just now, when 64-bit
> transaction ids are far from committable shape? Or do you think we
> don't need int64 GUCs even if we have 64-bit transaction ids? If yes,
> what do you think we should use for *_age variables with 64-bit
Hi Alexander
I think we need int64 GUCs, due to these parameters（
autovacuum_freeze_table_age, autovacuum_freeze_max_age,When a table age is
greater than any of these parameters an aggressive vacuum will be
performed, When we implementing xid64, is it still necessary to be in the
int range?
Hi, Tom!
On Wed, Sep 25, 2024 at 6:08 PM Tom Lane wrote:
> FWIW, I agree with the upthread opinions that we shouldn't do this
> (invent int64 GUCs). I don't think we need the added code bloat
> and risk of breaking user code that isn't expecting this new GUC
> type. We invented the notion of GU
FWIW, I agree with the upthread opinions that we shouldn't do this
(invent int64 GUCs). I don't think we need the added code bloat
and risk of breaking user code that isn't expecting this new GUC
type. We invented the notion of GUC units in part to ensure that
int32 GUCs could be adapted to handl
Hi,
> ```
> postgres=# alter system set autovacuum_vacuum_threshold to 2_147_483_648;
> ERROR: invalid value for parameter "autovacuum_vacuum_threshold":
> "2_147_483_648"
> postgres=# alter system set autovacuum_vacuum_threshold to 2_147_483_647;
> ALTER SYSTEM
> ```
>
> IIRC, the lexer only su
On Sep 25, 2024, at 19:03, Aleksander Alekseev wrote:
Hi,
I found the autovacuum_vacuum_threshold, autovacuum_vacuum_insert_threshold
and autovacuum_analyze_threshold is change to int64 for relation option,
however the GUCs are still integers.
```
postgres=# select * from pg_settings where nam
Hi,
> I found the autovacuum_vacuum_threshold, autovacuum_vacuum_insert_threshold
> and autovacuum_analyze_threshold is change to int64 for relation option,
> however the GUCs are still integers.
>
> ```
> postgres=# select * from pg_settings where name =
> 'autovacuum_vacuum_threshold' \gx
> -[
On Tue, Sep 24, 2024 at 12:27:20PM +0300, Aleksander Alekseev wrote:
>> It doesn't look like these *_age GUCs could benefit from being 64-bit,
>> before 64-bit transaction ids get in. However, I think there are some
>> better candidates.
>>
>> autovacuum_vacuum_threshold
>> autovacuum_vacuum_inser
Hi, Aleksander Alekseev
Thanks for updating the patch.
> On Sep 24, 2024, at 17:27, Aleksander Alekseev
> wrote:
>
> Hi, Alexander!
>
>> Thank you for your work on this subject.
>
> Thanks for your feedback.
>
>> It doesn't look like these *_age GUCs could benefit from being 64-bit,
>> befo
Hi,
> PFA the updated patch.
It is worth mentioning that v2 should not be merged as is.
Particularly although it changes the following GUCs:
> autovacuum_vacuum_threshold
> autovacuum_vacuum_insert_threshold
> autovacuum_analyze_threshold
... it doesn't affect the code that uses these GUCs whic
Hi, Alexander!
> Thank you for your work on this subject.
Thanks for your feedback.
> It doesn't look like these *_age GUCs could benefit from being 64-bit,
> before 64-bit transaction ids get in. However, I think there are some
> better candidates.
>
> autovacuum_vacuum_threshold
> autovacuum_
Hi, Aleksander!
Thank you for your work on this subject.
On Thu, Sep 12, 2024 at 2:08 PM Aleksander Alekseev
wrote:
> Attached is a self-sufficient patch extracted from a larger patchset
> [1]. The entire patchset probably will not proceed further in the
> nearest future. Since there was interes
On Thu, Sep 12, 2024 at 2:29 PM Pavel Borisov wrote:
> Hi, Alexander!
> Thank you for working on this!
>
> On Thu, 12 Sept 2024 at 15:08, Aleksander Alekseev
> wrote:
>>
>> Hi,
>>
>> Attached is a self-sufficient patch extracted from a larger patchset
>> [1]. The entire patchset probably will no
On Thu, Sep 12, 2024 at 02:08:15PM +0300, Aleksander Alekseev wrote:
> Secondly, the following core GUCs are made 64-bit:
>
> ```
> autovacuum_freeze_min_age
> autovacuum_freeze_max_age
> autovacuum_freeze_table_age
> autovacuum_multixact_freeze_min_age
> autovacuum_multixact_freeze_max_age
> auto
Hi Pavel,
> I think the direction is good and delivering 64-bit GUCs is very much worth
> committing.
> The patch itself looks good, but we could need to add locks against
> concurrently modifying 64-bit values, which could be non-atomic on older
> architectures.
Thanks for the feedback.
> I
Hi, Alexander!
Thank you for working on this!
On Thu, 12 Sept 2024 at 15:08, Aleksander Alekseev
wrote:
> Hi,
>
> Attached is a self-sufficient patch extracted from a larger patchset
> [1]. The entire patchset probably will not proceed further in the
> nearest future. Since there was interest in
Hi,
Attached is a self-sufficient patch extracted from a larger patchset
[1]. The entire patchset probably will not proceed further in the
nearest future. Since there was interest in this particular patch it
deserves being discussed in a separate thread.
Currently we support 32-bit integer values
19 matches
Mail list logo
