On Tue, Nov 1, 2022 at 3:17 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > Below are test results with v3 patch. +1 for back-patching it.
The problem with back-patching stuff like this is that it can have unanticipated consequences. I think that the chances of something like this backfiring are less than for a patch that changes plans, but I don't think that they're nil, either. It could turn out that this patch, which has really promising results on the workloads we've tested, harms some other workload due to some other contention pattern we can't foresee. It could also turn out that improving performance at the database level actually has negative consequences for some application using the database, because the application could be unknowingly relying on the database to throttle its activity. It's hard for me to estimate exactly what the risk of a patch like this is. I think that if we back-patched this, and only this, perhaps the chances of something bad happening aren't incredibly high. But if we get into the habit of back-patching seemingly-innocuous performance improvements, it's only a matter of time before one of them turns out not to be so innocuous as we thought. I would guess that the number of times we have to back-patch something like this before somebody starts complaining about a regression is likely to be somewhere between 3 and 5. It's possible that I'm too pessimistic, though. -- Robert Haas EDB: http://www.enterprisedb.com
