aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-03-10 10:22:08 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2025-03-10 10:22:08 -0400
commit9f87e2593febf0ff024c11b9a97703bce0eee7be (patch)
treed77691563f0ebd09916e1e05272e04525c909485 /doc/src
parent6bb6a62f3cc45624c601d5270673a17447734629 (diff)
downloadpostgresql-9f87e2593febf0ff024c11b9a97703bce0eee7be.tar.gz
postgresql-9f87e2593febf0ff024c11b9a97703bce0eee7be.zip
Doc: improve description of window function processing.
The previous wording talked about a "single pass over the data", which can be read as promising more than intended (to wit, that only one WindowAgg plan node will be used). What we promise is only what the SQL spec requires, namely that the data not get re-sorted between window functions with compatible PARTITION BY/ORDER BY clauses. Adjust the wording in hopes of making this clearer. Reported-by: Christopher Inokuchi <cinokuchi@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://postgr.es/m/CABde6B5va2wMsnM79u_x=n9KUgfKQje_pbLROEBmA9Ru5XWidw@mail.gmail.com Backpatch-through: 13
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/queries.sgml8
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index 372cce1a487..a326960ff4d 100644
--- a/doc/src/sgml/queries.sgml
+++ b/doc/src/sgml/queries.sgml
@@ -1461,10 +1461,10 @@ GROUP BY GROUPING SETS (
<para>
When multiple window functions are used, all the window functions having
- syntactically equivalent <literal>PARTITION BY</literal> and <literal>ORDER BY</literal>
- 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 <literal>ORDER BY</literal> does not uniquely determine an ordering.
+ equivalent <literal>PARTITION BY</literal> and <literal>ORDER BY</literal>
+ clauses in their window definitions are guaranteed to see the same
+ ordering of the input rows, even if the <literal>ORDER BY</literal> does
+ not uniquely determine the ordering.
However, no guarantees are made about the evaluation of functions having
different <literal>PARTITION BY</literal> or <literal>ORDER BY</literal> specifications.
(In such cases a sort step is typically required between the passes of