> On Oct 2, 2022, at 1:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > "Jonathan S. Katz" <jk...@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.
OK. > 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. OK. For v15 I am heavily in favor for the least risky approach given the point we are at in the release cycle. The RMT hasn’t met yet to discuss, but from re-reading this thread again, I would recommend to revert (i.e. the “straight up revert”). I’m less opinionated on the approach for what’s in HEAD, but the rewrite you suggest sounds promising. Thanks, Jonathan
