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

"Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
> 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”).

OK by me.

> I’m less opinionated on the approach for what’s in HEAD, but the rewrite
> you suggest sounds promising.

I'm just about to throw up my hands and go for reversion in both branches,
because I'm now discovering that the code I'd hoped to salvage in
pathkeys.c (get_useful_group_keys_orderings and related) has its very own
bugs. It's imagining that it can rearrange a PathKeys list arbitrarily
and then rearrange the GROUP BY SortGroupClause list to match, but that's
easier said than done, for a couple of different reasons. (I now
understand why db0d67db2 made a cowboy hack in get_eclass_for_sort_expr ...
but it's still a cowboy hack with difficult-to-foresee side effects.)
There are other things in there that make it painfully obvious that
this code wasn't very carefully reviewed, eg XXX comments that should
have been followed up and were not, or a reference to a nonexistent
"debug_group_by_match_order_by" flag (maybe that was a GUC at some point?).

On top of that, it's producing several distinct pathkey orderings for
the caller to try, but it's completely unclear to me that the subsequent
choice of cheapest path isn't going to largely reduce to the question
of whether we can accurately estimate the relative costs of different
sort-column orders. Which is exactly what we're finding we can't do.
So that end of it seems to need a good deal of rethinking as well.

In short, this needs a whole lotta work, and I'm not volunteering.

regards, tom lane