Re: Question: test "aggregates" failed in 32-bit machine - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Question: test "aggregates" failed in 32-bit machine
Date
Msg-id 1159680.1664730746@sss.pgh.pa.us
Whole thread Raw
In response to Re: Question: test "aggregates" failed in 32-bit machine  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: Question: test "aggregates" failed in 32-bit machine  ("Jonathan S. Katz" <jkatz@postgresql.org>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions
Next
From: Andres Freund
Date:
Subject: Re: Add support for DEFAULT specification in COPY FROM