From: | 谭忠涛 <zhongtao(dot)tan(at)seaboxdata(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-03 01:17:58 |
Message-ID: | tencent_36E46A690C75D7AE585BE432@qq.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thank you for your feedback.
regards
Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> 在 2025年1月3日 周五 0:04 写道:
"=?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 | PG Bug reporting form | 2025-01-03 07:36:29 | BUG #18764: server closed the connection unexpectedly |
Previous Message | 谭忠涛 | 2025-01-03 01:12:03 | 回复:Re: Incorrect sort result caused by ROLLUP and WHERE operation |