Thread

  1. Incorrect sort result caused by ROLLUP and WHERE operation

    谭忠涛 <zhongtao.tan@seaboxdata.com> — 2025-01-02T07:28:25Z

    Case:
    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;
    
    
    
    
    
    
    
    Regards
    
    
    
    谭忠涛&nbsp; &nbsp;数据研究院数据库事业部
    北京东方金信科技股份有限公司
    地址:海淀区知春路7号致真大厦 D 座 14 层
    路线:地铁10号线-西土城站-A口
    手机:13920129934
    公众号:东方金信
    网址:www.seaboxdata.com
    关于东方金信
    &nbsp; &nbsp; 北京东方金信科技股份有限公司成立于2013年2月。公司拥有ISO9001、 ISO27001和CMMI5级认证;中国大数据企业50强;首批通过工信部数据中心联盟大数据基础能力和性能双认证;首个国家信息中心“数据资产研究中心”授牌单位;全国信标委智慧城市及大数据标准工作组成员,2017年入选Gartner全球大数据行业和人工智能报告;2019年与腾讯云成为战略合作伙伴并获腾讯数亿元投资;2020年获中金、海淀区国资委入股。
  2. Re: Incorrect sort result caused by ROLLUP and WHERE operation

    Zhang Mingli <zmlpostgres@gmail.com> — 2025-01-02T10:49:26Z

    Hi,
    
    
    Zhang Mingli
    www.hashdata.xyz
    
    Do you mean order of null value (column a)  is wrong?
    Use NULLS FIRST/LAST to order null values.
    On Jan 2, 2025 at 18:19 +0800, 谭忠涛 <zhongtao.tan@seaboxdata.com>, wrote:
    >
    > Case:
    > 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;
    
  3. Re: Incorrect sort result caused by ROLLUP and WHERE operation

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-01-02T16:04:23Z

    "=?utf-8?B?6LCt5b+g5rab?=" <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 = 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