Re: Disabling Heap-Only Tuples
От | Laurenz Albe |
---|---|
Тема | Re: Disabling Heap-Only Tuples |
Дата | |
Msg-id | 0c899a4c548376b1949c0e861170739653b2da4e.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Disabling Heap-Only Tuples (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Disabling Heap-Only Tuples
|
Список | pgsql-hackers |
On Wed, 2023-08-30 at 09:31 -0400, Robert Haas wrote: > On Wed, Aug 30, 2023 at 9:01 AM Matthias van de Meent > <boekewurm+postgres@gmail.com> wrote: > > I've reworked the patch a bit to remove the "excessive bloat with low > > fillfactors when local space is available" issue that this parameter > > could cause - local updates are now done if the selected page we would > > be inserting into is after the old tuple's page and the old tuple's > > page still (or: now) has space available. > > > > Does that alleviate your concerns? > > That seems like a good chance, but my core concern is around people > having to micromanage local_update_limit, and probably either not > knowing how to do it properly, or not being able or willing to keep > updating it as things change. > > In a way, this parameter is a lot like work_mem, which is notoriously > very difficult to tune. I don't think that is a good comparison. While most people probably never need to touch "local_update_limit", "work_mem" is something everybody has to consider. And it is not so hard to tune: the setting would be the desired table size, and you could use pgstattuple to find a good value. I don't know what other use cases come to mind, but I see it as a tool to shrink a table after it has grown big holes, perhaps after a mass delete. Today, you can only VACUUM (FULL) or play with the likes of pg_squeeze and pg_repack. I think this is useful. To alleviate your concerns, perhaps it would help to describe the use case and ideas for a good setting in the documentation. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: