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
