Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxVOb-0005fm-5Q for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Nov 2022 15:41:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oxVOZ-0003Z7-RI for pgsql-bugs@arkaria.postgresql.org; Tue, 22 Nov 2022 15:41:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxVOZ-0003Yh-Ir for pgsql-bugs@lists.postgresql.org; Tue, 22 Nov 2022 15:41:11 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxVOW-0003Yv-WC for pgsql-bugs@lists.postgresql.org; Tue, 22 Nov 2022 15:41:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2AMFf6lF3455211; Tue, 22 Nov 2022 10:41:06 -0500 From: Tom Lane To: Chris Rohlfs cc: pgsql-bugs@lists.postgresql.org Subject: Re: Sort Order inconsistent when using Grouping Sets Rollup In-reply-to: References: Comments: In-reply-to Chris Rohlfs message dated "Mon, 21 Nov 2022 22:06:47 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3455208.1669131666.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2022 10:41:06 -0500 Message-ID: <3455209.1669131666@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Chris Rohlfs writes: > The attached file will create a table and run 2 queries, the first of wh= ich > is not honoring the requested sort order. I expect the Nulls first. Yeah, this is a known issue that's a bit difficult to fix. Because you've constrained both the first_name and last_name columns to have unique values: > where (( "actor_id" >=3D 1 ) and ( "last_name" =3D 'GUINESS' ) a= nd ( > "first_name" =3D 'PENELOPE' )) the planner is of the opinion that sorting on those columns is a no-op, so it doesn't bother to emit a sort step after the aggregation. We need to teach it that the output of GROUP BY, when there are grouping sets, is not identical to the input because of possible injection of null values. I'm working on some patches that should lead to that result, but they won't appear till v16 at the earliest. As a grotty workaround, you could do the ordering in a different query level: =3D# explain select * from ( select "last_name", "first_name", count("actor_id") from actor where (( "actor_id" >=3D 1 ) and ( "last_name" =3D 'GUINESS' ) and ( "fi= rst_name" =3D 'PENELOPE' )) group by rollup( 1, 2 ) ) ss order by 2 asc nulls first, 1 asc nulls first; QUERY PLAN = = --------------------------------------------------------------------------= ------------------------------------- Sort (cost=3D23.71..23.72 rows=3D3 width=3D72) Sort Key: actor.first_name NULLS FIRST, actor.last_name NULLS FIRST -> GroupAggregate (cost=3D0.00..23.69 rows=3D3 width=3D72) Group Key: actor.last_name, actor.first_name Group Key: actor.last_name Group Key: () -> Seq Scan on actor (cost=3D0.00..23.65 rows=3D1 width=3D68) Filter: ((actor_id >=3D 1) AND (last_name =3D 'GUINESS'::te= xt) AND (first_name =3D 'PENELOPE'::text)) (8 rows) regards, tom lane