Re: Question: test "aggregates" failed in 32-bit machine

> On Oct 2, 2022, at 1:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Jonathan S. Katz" <jkatz(at)postgresql(dot)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