On Wed, Aug 30, 2023 at 9:01 AM Matthias van de Meent <boekewurm+postg...@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