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. If you set it too high, you run out of memory.
If you set it too low, you get bad plans. You can switch from having
one of those problems to having the other very quickly as load changs,
and sometimes you can have both at the same time. If an omniscient
oracle could set work_mem properly for every query based not only on
what the query does but the state of the system at that moment, it
would still be a very crude parameter, and since omniscient oracles
are rare in practice, problems are reasonably common. I think that if
we add this parameter, it's going to end up in the same category. A
lot of people will ignore it, and they'll be OK, but 30% of the people
who do try to use it will shoot themselves in the foot, or something
like that.
--
Robert Haas
EDB: http://www.enterprisedb.com
