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

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, kuroda(dot)hayato(at)fujitsu(dot)com, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Question: test "aggregates" failed in 32-bit machine
Date: 2022-10-02 17:32:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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.


> 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.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-10-02 17:44:25 Re: Making pg_rewind faster
Previous Message Justin Pryzby 2022-10-02 17:25:20 Re: [RFC] building postgres with meson - v13