From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Disabling Heap-Only Tuples |
Date: | 2023-07-06 20:18:07 |
Message-ID: | CAEze2Wgzhcz2U4WYsTuXXYnTTxrVjwdhSfyuWTiVha+ttB8Vfg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 5 Jul 2023 at 19:55, Thom Brown <thom(at)linux(dot)com> wrote:
>
> On Wed, 5 Jul 2023 at 18:05, Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
> > So what were you thinking of? A session GUC? A table option?
>
> Both.
Here's a small patch implementing a new table option max_local_update
(name very much bikesheddable). Value is -1 (default, disabled) or the
size of the table in MiB that you still want to allow to update on the
same page. I didn't yet go for a GUC as I think that has too little
control on the impact on the system.
I decided that max_local_update would be in MB because there is no
reloption value that can contain MaxBlockNumber and -1/disabled; and 1
MiB seems like enough granularity for essentially all use cases.
The added regression tests show how this feature works, that the new
feature works, and validate that lock levels are acceptable
(ShareUpdateExclusiveLock, same as for updating fillfactor).
Kind regards,
Matthias van de Meent
Neon (https://neon.tech/)
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Implement-a-reloption-that-forces-updated-tuples-.patch | application/octet-stream | 10.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-07-06 20:29:19 | BUG #18016: REINDEX TABLE failure |
Previous Message | Justin Pryzby | 2023-07-06 20:15:19 | Re: warn if GUC set to an invalid shared library |