Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tr0CJ-00DMsg-Dr for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Mar 2025 19:50:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tr0CH-007ZE2-Nv for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Mar 2025 19:50:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tr0CH-007ZB8-Ej for pgsql-bugs@lists.postgresql.org; Sat, 08 Mar 2025 19:50:57 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tr0CF-001j4H-1p for pgsql-bugs@lists.postgresql.org; Sat, 08 Mar 2025 19:50:56 +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 528Joq3x029120; Sat, 8 Mar 2025 14:50:52 -0500 From: Tom Lane To: "David G. Johnston" cc: Christopher Inokuchi , Greg Sabino Mullane , pgsql-bugs@lists.postgresql.org Subject: Re: Window Functions with identical PARTITION BY and ORDER BY clauses evaluated separately In-reply-to: References: <1147307.1741392351@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Fri, 07 Mar 2025 20:17:23 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <29118.1741463452.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Sat, 08 Mar 2025 14:50:52 -0500 Message-ID: <29119.1741463452@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Fri, Mar 7, 2025 at 5:05 PM Tom Lane wrote: >> Perhaps the wording in section 7.2.5 could be improved; I agree >> that "evaluated in one pass" is capable of being read in more >> than one way, and it's not clear that it's referring to sorts. >> Do you have any suggestions for clearer wording? > We seem to do quite a few things that we don't tell the user about. The > attached patch describes those things and adds an example demonstrating > their effects via an explain; which is the only way you can construct an > example for this material. > Considered a draft pending feedback to either throw it out in favor of a > one-word/one-line fix or support for going into this amount of detail. Meh. This is detail that wasn't asked for and doesn't belong in this section anyway. (If we did want to write something like this, chapter 14 Performance Tips would be a more plausible home I think. That'd at least remove the problem of forward-referencing EXPLAIN output.) For a shorter fix, maybe replace the first two sentences When multiple window functions are used, all the window functions having syntactically equivalent PARTITION BY and ORDER BY clauses in their window definitions are guaranteed to be evaluated in a single pass over the data. Therefore they will see the same sort ordering, even if the ORDER BY does not uniquely determine an ordering. with When multiple window functions are used, all the window functions having syntactically equivalent PARTITION BY and ORDER BY clauses in their window definitions are guaranteed to see the same ordering of the input rows, even if the ORDER BY does not uniquely determine the ordering. regards, tom lane