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 1pDGIi-0005xI-TM for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 02:48:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pDGIg-0001Q3-Kk for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 02:48:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDGIg-0001Pt-BT for pgsql-hackers@lists.postgresql.org; Thu, 05 Jan 2023 02:48:14 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDGIZ-0007m3-Hk for pgsql-hackers@lists.postgresql.org; Thu, 05 Jan 2023 02:48:13 +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 3052m5hR2408234; Wed, 4 Jan 2023 21:48:05 -0500 From: Tom Lane To: Vik Fearing cc: Ankit Kumar Pandey , David Rowley , pghackers Subject: Re: Todo: Teach planner to evaluate multiple windows in the optimal order In-reply-to: <441d135e-1941-c3ef-1649-18c3e8811549@postgresfriends.org> References: <83d80853-a45c-d85c-68eb-59acfe7fb5fb@gmail.com> <7f77ee7d-bd04-d8e2-bb34-42395fd1f7c2@gmail.com> <6ebcc137-45ea-6373-e3e1-3c304c452e1f@gmail.com> <441d135e-1941-c3ef-1649-18c3e8811549@postgresfriends.org> Comments: In-reply-to Vik Fearing message dated "Thu, 05 Jan 2023 03:18:24 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2408232.1672886885.1@sss.pgh.pa.us> Date: Wed, 04 Jan 2023 21:48:05 -0500 Message-ID: <2408233.1672886885@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Vik Fearing writes: > On 1/4/23 13:07, Ankit Kumar Pandey wrote: >> Also, one thing, consider the following query: >> explain analyze select row_number() over (order by a,b),count(*) over >> (order by a) from abcd order by a,b,c; >> In this case, sorting is done on (a,b) followed by incremental sort on c >> at final stage. >> If we do just one sort: a,b,c at first stage then there won't be need to >> do another sort (incremental one). > This could give incorrect results. Mmmm ... your counterexample doesn't really prove that. Yes, the "rank()" step must consider only two ORDER BY columns while deciding which rows are peers, but I don't see why it wouldn't be okay if the rows happened to already be sorted by "c" within those peer groups. I don't recall the implementation details well enough to be sure how hard it would be to keep that straight. regards, tom lane