From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | 谭忠涛 <zhongtao(dot)tan(at)seaboxdata(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Incorrect sort result caused by ROLLUP and WHERE operation |
Date: | 2025-01-02 16:04:23 |
Message-ID: | 270213.1735833863@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"=?utf-8?B?6LCt5b+g5rab?=" <zhongtao(dot)tan(at)seaboxdata(dot)com> writes:
> create table t1(a int, b int);
> insert into t1 values(1,1),(1,2);
> select a,b,sum(10) as s from t1 where a = 1 group by rollup(a,b) order by a, s desc;
Yeah. This is fixed in HEAD (v18-to-be) but the fix is too invasive
to consider back-patching. Basically the problem is that older
versions don't understand that the post-ROLLUP value of "a" can be
different from the pre-ROLLUP value, so they think the "where a = 1"
clause removes any need to sort by "a".
As a workaround you could write something like "order by a+0, s desc"
to fool the optimizer into considering the ordering column to be
different from the value that's constrained by WHERE.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Wendorff | 2025-01-02 22:02:27 | BRIN index creation on geometry column causes crash |
Previous Message | Tom Lane | 2025-01-02 15:53:01 | Re: AW: Commit 5a2fed911a broke parallel query |