From: Tom Lane <tgl@sss.pgh.pa.us>
To: "=?utf-8?B?6LCt5b+g5rab?=" <zhongtao.tan@seaboxdata.com>
cc: "=?utf-8?B?cGdzcWwtYnVncw==?=" <pgsql-bugs@lists.postgresql.org>
Subject: Re: Incorrect sort result caused by ROLLUP and WHERE operation
In-reply-to: <tencent_4568C7826D8BDEF01BC56D3D@qq.com>
References: <tencent_4568C7826D8BDEF01BC56D3D@qq.com>
Comments: In-reply-to "=?utf-8?B?6LCt5b+g5rab?=" <zhongtao.tan@seaboxdata.com>
	message dated "Thu, 02 Jan 2025 15:28:25 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <270212.1735833863.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 02 Jan 2025 11:04:23 -0500
Message-ID: <270213.1735833863@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/270213.1735833863%40sss.pgh.pa.us>
Precedence: bulk

"=3D?utf-8?B?6LCt5b+g5rab?=3D" <zhongtao.tan@seaboxdata.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 =3D 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 =3D 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