Re: Question: test "aggregates" failed in 32-bit machine
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
"kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
John Naylor <john.naylor@enterprisedb.com>,
Michael Paquier <michael@paquier.xyz>
Date: 2022-10-02T17:12:26Z
Lists: pgsql-hackers
"Jonathan S. Katz" <jkatz@postgresql.org> writes: > On 10/1/22 6:57 PM, Tom Lane wrote: >> I plan to have a look tomorrow at the idea of reverting only the cost_sort >> changes, and rewriting get_cheapest_group_keys_order() to just sort the >> keys by decreasing numgroups estimates as I suggested upthread. That >> might be substantially less messy, because of fewer interactions with >> 1349d2790. > Maybe this leads to a follow-up question of do we continue to improve > what is in HEAD while reverting the code in v15 (particularly if it's > easier to do it that way)? No. I see no prospect that the cost_sort code currently in HEAD is going to become shippable in the near future. Quite aside from the plain bugs, I think it's based on untenable assumptions about how accurately we can estimate the CPU costs associated with different sort-column orders. Having said that, it's certainly possible that we should do something different in HEAD than in v15. We could do the rewrite I suggest above in HEAD while doing a straight-up revert in v15. I've been finding that 1349d2790 is sufficiently entwined with this code that the patches would look significantly different in any case, so that might be the most reliable way to proceed in v15. regards, tom lane
Commits
-
Revert "Optimize order of GROUP BY keys".
- f4c7c410ee4a 16.0 landed
- 443df6e2db93 15.0 landed