Re: PG15 beta1 sort performance regression due to Generation context change
От | Jonathan S. Katz |
---|---|
Тема | Re: PG15 beta1 sort performance regression due to Generation context change |
Дата | |
Msg-id | 34addd0c-eda0-aa60-094c-c2644a2c3fce@postgresql.org обсуждение исходный текст |
Ответ на | Re: PG15 beta1 sort performance regression due to Generation context change (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PG15 beta1 sort performance regression due to Generation context change
Re: PG15 beta1 sort performance regression due to Generation context change Re: PG15 beta1 sort performance regression due to Generation context change |
Список | pgsql-hackers |
On 7/15/22 4:54 PM, Tom Lane wrote: > Tomas Vondra <tomas.vondra@enterprisedb.com> writes: >> ... My personal opinion is that it's a rare regression. Other >> optimization patches have similar rare regressions, except that David >> spent so much time investigating this one it seems more serious. > > Yeah, this. I fear we're making a mountain out of a molehill. We have > committed many optimizations that win on average but possibly lose > in edge cases, and not worried too much about it. I disagree with the notion of this being a "mountain out of a molehill." The RMT looked at the situation, asked if we should make one more pass. There were logical argument as to why not to (e.g. v16 efforts). I think that is reasonable, and we can move on from any additional code changes for v15. What I find interesting is the resistance to adding any documentation around this feature to guide users in case they hit the regression. I understand it can be difficult to provide guidance on issues related to adjusting work_mem, but even just a hint in the release notes to say "if you see a performance regression you may need to adjust work_mem" would be helpful. This would help people who are planning upgrades to at least know what to watch out for. If that still seems unreasonable, I'll agree to disagree so we can move on with other parts of the release. Jonathan
Вложения
В списке pgsql-hackers по дате отправления: