1
0
mirror of https://github.com/postgres/postgres.git synced 2025-08-30 06:01:21 +03:00

Support window functions a la SQL:2008.

Hitoshi Harada, with some kibitzing from Heikki and Tom.
This commit is contained in:
Tom Lane
2008-12-28 18:54:01 +00:00
parent 38e9348282
commit 95b07bc7f5
92 changed files with 6720 additions and 321 deletions

View File

@@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.50 2008/10/14 00:41:34 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.51 2008/12/28 18:53:54 tgl Exp $ -->
<chapter id="queries">
<title>Queries</title>
@@ -949,6 +949,57 @@ SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit
5000. Note that the aggregate expressions do not necessarily need
to be the same in all parts of the query.
</para>
<para>
If a query contains aggregate function calls, but no <literal>GROUP BY</>
clause, grouping still occurs: the result is a single group row (or
perhaps no rows at all, if the single row is then eliminated by
<literal>HAVING</>).
The same is true if it contains a <literal>HAVING</> clause, even
without any aggregate function calls or <literal>GROUP BY</> clause.
</para>
</sect2>
<sect2 id="queries-window">
<title>Window Function Processing</>
<indexterm zone="queries-window">
<primary>window function</primary>
<secondary>order of execution</>
</indexterm>
<para>
If the query contains any window functions (see
<xref linkend="tutorial-window"> and
<xref linkend="syntax-window-functions">), these functions are evaluated
after any grouping, aggregation, and <literal>HAVING</> filtering is
performed. That is, if the query uses any aggregates, <literal>GROUP
BY</>, or <literal>HAVING</>, then the rows seen by the window functions
are the group rows instead of the original table rows from
<literal>FROM</>/<literal>WHERE</>.
</para>
<para>
When multiple window functions are used, all the window functions having
syntactically equivalent <literal>PARTITION BY</> and <literal>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 <literal>ORDER BY</> does not uniquely determine an ordering.
However, no guarantees are made about the evaluation of functions having
different <literal>PARTITION BY</> or <literal>ORDER BY</> specifications.
(In such cases a sort step is typically required between the passes of
window function evaluations, and the sort is not guaranteed to preserve
ordering of rows that its <literal>ORDER BY</> sees as equivalent.)
</para>
<para>
Currently, use of window functions always forces sorting, and so the
query output will be ordered according to one or another of the window
functions' <literal>PARTITION BY</>/<literal>ORDER BY</> clauses.
It is not recommendable to rely on this, however. Use an explicit
top-level <literal>ORDER BY</> clause if you want to be sure the
results are sorted in a particular way.
</para>
</sect2>
</sect1>