On Thu, 11 May 2023 at 01:00, Alexander Lakhin <exclus...@gmail.com> wrote: > This time `git bisect` pointed at 3c6fc5820. Having compared execution plans > (both attached), I see the following differences (3c6fc5820~1 vs 3c6fc5820):
Based on what you've sent, I'm uninspired to want to try to do anything about it. The patched version finds a plan that's cheaper. The row estimates are miles off with both plans. I'm not sure what we're supposed to do here. It's pretty hard to make changes to the planner's path generation without risking that a bad plan is chosen when it wasn't beforehand with bad row estimates. Is the new plan still slower if you increase work_mem so that the sort no longer goes to disk? Maybe the planner would have picked Hash Aggregate if the row estimates had been such that cost_tuplesort() knew that the sort would have gone to disk. David
