From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Disabling Heap-Only Tuples |
Date: | 2023-08-24 16:23:18 |
Message-ID: | CAEze2WiPB1MsT37RopnDGsd1TM8kqW3pT+ugVZcJBJ7wb=RzXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 19 Jul 2023 at 15:13, Thom Brown <thom(at)linux(dot)com> wrote:
>
> On Wed, 19 Jul 2023, 13:58 Laurenz Albe, <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>> I agree that the name "max_local_update" could be improved.
>> Perhaps "avoid_hot_above_size_mb".
>
> Or "hot_table_size_threshold" or "hot_update_limit"?
Although I like these names, it doesn't quite cover the use of the
parameter for me, as updated tuples prefer to be inserted on the same
page as the old tuple regardless of whether HOT applies.
Example: a bloated table test(
id int primary key,
num_updates int,
unique (id, num_updates)
)
would be assumed to remain bloated if I'd set a parameter named
something_hot_something, as all updates would be non-hot and thus
should not be influenced by the GUC/parameter.
How about 'local_update_limit'?
Kind regards,
Matthias van de Meent
From | Date | Subject | |
---|---|---|---|
Next Message | Nazir Bilal Yavuz | 2023-08-24 16:41:00 | Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc? |
Previous Message | Nathan Bossart | 2023-08-24 16:19:13 | Re: pg_stat_get_backend_subxact() and backend IDs? |