1999-10-24 22:42:27 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* catversion.h
|
2003-01-24 00:39:07 +01:00
|
|
|
* "Catalog version number" for PostgreSQL.
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
|
|
|
|
* The catalog version number is used to flag incompatible changes in
|
2008-12-19 17:25:19 +01:00
|
|
|
* the PostgreSQL system catalogs. Whenever anyone changes the format of
|
1999-10-24 22:42:27 +02:00
|
|
|
* a system catalog relation, or adds, deletes, or modifies standard
|
|
|
|
|
* catalog entries in such a way that an updated backend wouldn't work
|
|
|
|
|
* with an old database (or vice versa), the catalog version number
|
|
|
|
|
* should be changed. The version number stored in pg_control by initdb
|
|
|
|
|
* is checked against the version number compiled into the backend at
|
|
|
|
|
* startup time, so that a backend can refuse to run in an incompatible
|
|
|
|
|
* database.
|
|
|
|
|
*
|
|
|
|
|
* The point of this feature is to provide a finer grain of compatibility
|
|
|
|
|
* checking than is possible from looking at the major version number
|
|
|
|
|
* stored in PG_VERSION. It shouldn't matter to end users, but during
|
|
|
|
|
* development cycles we usually make quite a few incompatible changes
|
|
|
|
|
* to the contents of the system catalogs, and we don't want to bump the
|
|
|
|
|
* major version number for each one. What we can do instead is bump
|
|
|
|
|
* this internal version number. This should save some grief for
|
|
|
|
|
* developers who might otherwise waste time tracking down "bugs" that
|
|
|
|
|
* are really just code-vs-database incompatibilities.
|
|
|
|
|
*
|
|
|
|
|
* The rule for developers is: if you commit a change that requires
|
|
|
|
|
* an initdb, you should update the catalog version number (as well as
|
2019-08-05 05:14:58 +02:00
|
|
|
* notifying the pgsql-hackers mailing list, which has been the
|
|
|
|
|
* informal practice for a long time).
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
|
|
|
|
* The catalog version number is placed here since modifying files in
|
|
|
|
|
* include/catalog is the most common kind of initdb-forcing change.
|
|
|
|
|
* But it could be used to protect any kind of incompatible change in
|
|
|
|
|
* database contents or layout, such as altering tuple headers.
|
|
|
|
|
*
|
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/catversion.h
|
1999-10-24 22:42:27 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef CATVERSION_H
|
|
|
|
|
#define CATVERSION_H
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We could use anything we wanted for version numbers, but I recommend
|
|
|
|
|
* following the "YYYYMMDDN" style often used for DNS zone serial numbers.
|
|
|
|
|
* YYYYMMDD are the date of the change, and N is the number of the change
|
|
|
|
|
* on that day. (Hopefully we'll never commit ten independent sets of
|
|
|
|
|
* catalog changes on the same day...)
|
|
|
|
|
*/
|
|
|
|
|
|
2000-11-12 01:37:02 +01:00
|
|
|
/* yyyymmddN */
|
Teach planner and executor about monotonic window funcs
Window functions such as row_number() always return a value higher than
the previously returned value for tuples in any given window partition.
Traditionally queries such as;
SELECT * FROM (
SELECT *, row_number() over (order by c) rn
FROM t
) t WHERE rn <= 10;
were executed fairly inefficiently. Neither the query planner nor the
executor knew that once rn made it to 11 that nothing further would match
the outer query's WHERE clause. It would blindly continue until all
tuples were exhausted from the subquery.
Here we implement means to make the above execute more efficiently.
This is done by way of adding a pg_proc.prosupport function to various of
the built-in window functions and adding supporting code to allow the
support function to inform the planner if the window function is
monotonically increasing, monotonically decreasing, both or neither. The
planner is then able to make use of that information and possibly allow
the executor to short-circuit execution by way of adding a "run condition"
to the WindowAgg to allow it to determine if some of its execution work
can be skipped.
This "run condition" is not like a normal filter. These run conditions
are only built using quals comparing values to monotonic window functions.
For monotonic increasing functions, quals making use of the btree
operators for <, <= and = can be used (assuming the window function column
is on the left). You can see here that once such a condition becomes false
that a monotonic increasing function could never make it subsequently true
again. For monotonically decreasing functions the >, >= and = btree
operators for the given type can be used for run conditions.
The best-case situation for this is when there is a single WindowAgg node
without a PARTITION BY clause. Here when the run condition becomes false
the WindowAgg node can simply return NULL. No more tuples will ever match
the run condition. It's a little more complex when there is a PARTITION
BY clause. In this case, we cannot return NULL as we must still process
other partitions. To speed this case up we pull tuples from the outer
plan to check if they're from the same partition and simply discard them
if they are. When we find a tuple belonging to another partition we start
processing as normal again until the run condition becomes false or we run
out of tuples to process.
When there are multiple WindowAgg nodes to evaluate then this complicates
the situation. For intermediate WindowAggs we must ensure we always
return all tuples to the calling node. Any filtering done could lead to
incorrect results in WindowAgg nodes above. For all intermediate nodes,
we can still save some work when the run condition becomes false. We've
no need to evaluate the WindowFuncs anymore. Other WindowAgg nodes cannot
reference the value of these and these tuples will not appear in the final
result anyway. The savings here are small in comparison to what can be
saved in the top-level WingowAgg, but still worthwhile.
Intermediate WindowAgg nodes never filter out tuples, but here we change
WindowAgg so that the top-level WindowAgg filters out tuples that don't
match the intermediate WindowAgg node's run condition. Such filters
appear in the "Filter" clause in EXPLAIN for the top-level WindowAgg node.
Here we add prosupport functions to allow the above to work for;
row_number(), rank(), dense_rank(), count(*) and count(expr). It appears
technically possible to do the same for min() and max(), however, it seems
unlikely to be useful enough, so that's not done here.
Bump catversion
Author: David Rowley
Reviewed-by: Andy Fan, Zhihong Yu
Discussion: https://postgr.es/m/CAApHDvqvp3At8++yF8ij06sdcoo1S_b2YoaT9D4Nf+MObzsrLQ@mail.gmail.com
2022-04-08 00:34:36 +02:00
|
|
|
#define CATALOG_VERSION_NO 202204076
|
2001-10-28 07:26:15 +01:00
|
|
|
|
1999-10-24 22:42:27 +02:00
|
|
|
#endif
|
