|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* windowfuncs.c
|
|
|
|
|
* Standard window functions defined in SQL spec.
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 2000-2023, PostgreSQL Global Development Group
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* IDENTIFICATION
|
|
|
|
|
* src/backend/utils/adt/windowfuncs.c
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
|
|
#include "nodes/parsenodes.h"
|
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
4 years ago
|
|
|
#include "nodes/supportnodes.h"
|
|
|
|
|
#include "utils/builtins.h"
|
|
|
|
|
#include "windowapi.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ranking process information
|
|
|
|
|
*/
|
|
|
|
|
typedef struct rank_context
|
|
|
|
|
{
|
|
|
|
|
int64 rank; /* current rank */
|
|
|
|
|
} rank_context;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ntile process information
|
|
|
|
|
*/
|
|
|
|
|
typedef struct
|
|
|
|
|
{
|
|
|
|
|
int32 ntile; /* current result */
|
|
|
|
|
int64 rows_per_bucket; /* row number of current bucket */
|
|
|
|
|
int64 boundary; /* how many rows should be in the bucket */
|
|
|
|
|
int64 remainder; /* (total rows) % (bucket num) */
|
|
|
|
|
} ntile_context;
|
|
|
|
|
|
|
|
|
|
static bool rank_up(WindowObject winobj);
|
|
|
|
|
static Datum leadlag_common(FunctionCallInfo fcinfo,
|
|
|
|
|
bool forward, bool withoffset, bool withdefault);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* utility routine for *_rank functions.
|
|
|
|
|
*/
|
|
|
|
|
static bool
|
|
|
|
|
rank_up(WindowObject winobj)
|
|
|
|
|
{
|
|
|
|
|
bool up = false; /* should rank increase? */
|
|
|
|
|
int64 curpos = WinGetCurrentPosition(winobj);
|
|
|
|
|
rank_context *context;
|
|
|
|
|
|
|
|
|
|
context = (rank_context *)
|
|
|
|
|
WinGetPartitionLocalMemory(winobj, sizeof(rank_context));
|
|
|
|
|
|
|
|
|
|
if (context->rank == 0)
|
|
|
|
|
{
|
|
|
|
|
/* first call: rank of first row is always 1 */
|
|
|
|
|
Assert(curpos == 0);
|
|
|
|
|
context->rank = 1;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
Assert(curpos > 0);
|
|
|
|
|
/* do current and prior tuples match by ORDER BY clause? */
|
|
|
|
|
if (!WinRowsArePeers(winobj, curpos - 1, curpos))
|
|
|
|
|
up = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We can advance the mark, but only *after* access to prior row */
|
|
|
|
|
WinSetMarkPosition(winobj, curpos);
|
|
|
|
|
|
|
|
|
|
return up;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* row_number
|
|
|
|
|
* just increment up from 1 until current partition finishes.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_row_number(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
int64 curpos = WinGetCurrentPosition(winobj);
|
|
|
|
|
|
|
|
|
|
WinSetMarkPosition(winobj, curpos);
|
|
|
|
|
PG_RETURN_INT64(curpos + 1);
|
|
|
|
|
}
|
|
|
|
|
|
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
4 years ago
|
|
|
/*
|
|
|
|
|
* window_row_number_support
|
|
|
|
|
* prosupport function for window_row_number()
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_row_number_support(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
Node *rawreq = (Node *) PG_GETARG_POINTER(0);
|
|
|
|
|
|
|
|
|
|
if (IsA(rawreq, SupportRequestWFuncMonotonic))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestWFuncMonotonic *req = (SupportRequestWFuncMonotonic *) rawreq;
|
|
|
|
|
|
|
|
|
|
/* row_number() is monotonically increasing */
|
|
|
|
|
req->monotonic = MONOTONICFUNC_INCREASING;
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
if (IsA(rawreq, SupportRequestOptimizeWindowClause))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestOptimizeWindowClause *req = (SupportRequestOptimizeWindowClause *) rawreq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The frame options can always become "ROWS BETWEEN UNBOUNDED
|
|
|
|
|
* PRECEDING AND CURRENT ROW". row_number() always just increments by
|
|
|
|
|
* 1 with each row in the partition. Using ROWS instead of RANGE
|
|
|
|
|
* saves effort checking peer rows during execution.
|
|
|
|
|
*/
|
|
|
|
|
req->frameOptions = (FRAMEOPTION_NONDEFAULT |
|
|
|
|
|
FRAMEOPTION_ROWS |
|
|
|
|
|
FRAMEOPTION_START_UNBOUNDED_PRECEDING |
|
|
|
|
|
FRAMEOPTION_END_CURRENT_ROW);
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
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
4 years ago
|
|
|
PG_RETURN_POINTER(NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* rank
|
|
|
|
|
* Rank changes when key columns change.
|
|
|
|
|
* The new rank number is the current row number.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_rank(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
rank_context *context;
|
|
|
|
|
bool up;
|
|
|
|
|
|
|
|
|
|
up = rank_up(winobj);
|
|
|
|
|
context = (rank_context *)
|
|
|
|
|
WinGetPartitionLocalMemory(winobj, sizeof(rank_context));
|
|
|
|
|
if (up)
|
|
|
|
|
context->rank = WinGetCurrentPosition(winobj) + 1;
|
|
|
|
|
|
|
|
|
|
PG_RETURN_INT64(context->rank);
|
|
|
|
|
}
|
|
|
|
|
|
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
4 years ago
|
|
|
/*
|
|
|
|
|
* window_rank_support
|
|
|
|
|
* prosupport function for window_rank()
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_rank_support(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
Node *rawreq = (Node *) PG_GETARG_POINTER(0);
|
|
|
|
|
|
|
|
|
|
if (IsA(rawreq, SupportRequestWFuncMonotonic))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestWFuncMonotonic *req = (SupportRequestWFuncMonotonic *) rawreq;
|
|
|
|
|
|
|
|
|
|
/* rank() is monotonically increasing */
|
|
|
|
|
req->monotonic = MONOTONICFUNC_INCREASING;
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
if (IsA(rawreq, SupportRequestOptimizeWindowClause))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestOptimizeWindowClause *req = (SupportRequestOptimizeWindowClause *) rawreq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* rank() is coded in such a way that it returns "(COUNT (*) OVER
|
|
|
|
|
* (<opt> RANGE UNBOUNDED PRECEDING) - COUNT (*) OVER (<opt> RANGE
|
|
|
|
|
* CURRENT ROW) + 1)" regardless of the frame options. We'll set the
|
|
|
|
|
* frame options to "ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW"
|
|
|
|
|
* so they agree with what window_row_number_support() optimized the
|
|
|
|
|
* frame options to be. Using ROWS instead of RANGE saves from doing
|
|
|
|
|
* peer row checks during execution.
|
|
|
|
|
*/
|
|
|
|
|
req->frameOptions = (FRAMEOPTION_NONDEFAULT |
|
|
|
|
|
FRAMEOPTION_ROWS |
|
|
|
|
|
FRAMEOPTION_START_UNBOUNDED_PRECEDING |
|
|
|
|
|
FRAMEOPTION_END_CURRENT_ROW);
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
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
4 years ago
|
|
|
PG_RETURN_POINTER(NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* dense_rank
|
|
|
|
|
* Rank increases by 1 when key columns change.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_dense_rank(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
rank_context *context;
|
|
|
|
|
bool up;
|
|
|
|
|
|
|
|
|
|
up = rank_up(winobj);
|
|
|
|
|
context = (rank_context *)
|
|
|
|
|
WinGetPartitionLocalMemory(winobj, sizeof(rank_context));
|
|
|
|
|
if (up)
|
|
|
|
|
context->rank++;
|
|
|
|
|
|
|
|
|
|
PG_RETURN_INT64(context->rank);
|
|
|
|
|
}
|
|
|
|
|
|
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
4 years ago
|
|
|
/*
|
|
|
|
|
* window_dense_rank_support
|
|
|
|
|
* prosupport function for window_dense_rank()
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_dense_rank_support(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
Node *rawreq = (Node *) PG_GETARG_POINTER(0);
|
|
|
|
|
|
|
|
|
|
if (IsA(rawreq, SupportRequestWFuncMonotonic))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestWFuncMonotonic *req = (SupportRequestWFuncMonotonic *) rawreq;
|
|
|
|
|
|
|
|
|
|
/* dense_rank() is monotonically increasing */
|
|
|
|
|
req->monotonic = MONOTONICFUNC_INCREASING;
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
if (IsA(rawreq, SupportRequestOptimizeWindowClause))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestOptimizeWindowClause *req = (SupportRequestOptimizeWindowClause *) rawreq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* dense_rank() is unaffected by the frame options. Here we set the
|
|
|
|
|
* frame options to match what's done in row_number's support
|
|
|
|
|
* function. Using ROWS instead of RANGE (the default) saves the
|
|
|
|
|
* executor from having to check for peer rows.
|
|
|
|
|
*/
|
|
|
|
|
req->frameOptions = (FRAMEOPTION_NONDEFAULT |
|
|
|
|
|
FRAMEOPTION_ROWS |
|
|
|
|
|
FRAMEOPTION_START_UNBOUNDED_PRECEDING |
|
|
|
|
|
FRAMEOPTION_END_CURRENT_ROW);
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
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
4 years ago
|
|
|
PG_RETURN_POINTER(NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* percent_rank
|
|
|
|
|
* return fraction between 0 and 1 inclusive,
|
|
|
|
|
* which is described as (RK - 1) / (NR - 1), where RK is the current row's
|
|
|
|
|
* rank and NR is the total number of rows, per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_percent_rank(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
rank_context *context;
|
|
|
|
|
bool up;
|
|
|
|
|
int64 totalrows = WinGetPartitionRowCount(winobj);
|
|
|
|
|
|
|
|
|
|
Assert(totalrows > 0);
|
|
|
|
|
|
|
|
|
|
up = rank_up(winobj);
|
|
|
|
|
context = (rank_context *)
|
|
|
|
|
WinGetPartitionLocalMemory(winobj, sizeof(rank_context));
|
|
|
|
|
if (up)
|
|
|
|
|
context->rank = WinGetCurrentPosition(winobj) + 1;
|
|
|
|
|
|
|
|
|
|
/* return zero if there's only one row, per spec */
|
|
|
|
|
if (totalrows <= 1)
|
|
|
|
|
PG_RETURN_FLOAT8(0.0);
|
|
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8((float8) (context->rank - 1) / (float8) (totalrows - 1));
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
/*
|
|
|
|
|
* window_percent_rank_support
|
|
|
|
|
* prosupport function for window_percent_rank()
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_percent_rank_support(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
Node *rawreq = (Node *) PG_GETARG_POINTER(0);
|
|
|
|
|
|
|
|
|
|
if (IsA(rawreq, SupportRequestWFuncMonotonic))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestWFuncMonotonic *req = (SupportRequestWFuncMonotonic *) rawreq;
|
|
|
|
|
|
|
|
|
|
/* percent_rank() is monotonically increasing */
|
|
|
|
|
req->monotonic = MONOTONICFUNC_INCREASING;
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
if (IsA(rawreq, SupportRequestOptimizeWindowClause))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestOptimizeWindowClause *req = (SupportRequestOptimizeWindowClause *) rawreq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* percent_rank() is unaffected by the frame options. Here we set the
|
|
|
|
|
* frame options to match what's done in row_number's support
|
|
|
|
|
* function. Using ROWS instead of RANGE (the default) saves the
|
|
|
|
|
* executor from having to check for peer rows.
|
|
|
|
|
*/
|
|
|
|
|
req->frameOptions = (FRAMEOPTION_NONDEFAULT |
|
|
|
|
|
FRAMEOPTION_ROWS |
|
|
|
|
|
FRAMEOPTION_START_UNBOUNDED_PRECEDING |
|
|
|
|
|
FRAMEOPTION_END_CURRENT_ROW);
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* cume_dist
|
|
|
|
|
* return fraction between 0 and 1 inclusive,
|
|
|
|
|
* which is described as NP / NR, where NP is the number of rows preceding or
|
|
|
|
|
* peers to the current row, and NR is the total number of rows, per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_cume_dist(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
rank_context *context;
|
|
|
|
|
bool up;
|
|
|
|
|
int64 totalrows = WinGetPartitionRowCount(winobj);
|
|
|
|
|
|
|
|
|
|
Assert(totalrows > 0);
|
|
|
|
|
|
|
|
|
|
up = rank_up(winobj);
|
|
|
|
|
context = (rank_context *)
|
|
|
|
|
WinGetPartitionLocalMemory(winobj, sizeof(rank_context));
|
|
|
|
|
if (up || context->rank == 1)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* The current row is not peer to prior row or is just the first, so
|
|
|
|
|
* count up the number of rows that are peer to the current.
|
|
|
|
|
*/
|
|
|
|
|
int64 row;
|
|
|
|
|
|
|
|
|
|
context->rank = WinGetCurrentPosition(winobj) + 1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* start from current + 1
|
|
|
|
|
*/
|
|
|
|
|
for (row = context->rank; row < totalrows; row++)
|
|
|
|
|
{
|
|
|
|
|
if (!WinRowsArePeers(winobj, row - 1, row))
|
|
|
|
|
break;
|
|
|
|
|
context->rank++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8((float8) context->rank / (float8) totalrows);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
/*
|
|
|
|
|
* window_cume_dist_support
|
|
|
|
|
* prosupport function for window_cume_dist()
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_cume_dist_support(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
Node *rawreq = (Node *) PG_GETARG_POINTER(0);
|
|
|
|
|
|
|
|
|
|
if (IsA(rawreq, SupportRequestWFuncMonotonic))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestWFuncMonotonic *req = (SupportRequestWFuncMonotonic *) rawreq;
|
|
|
|
|
|
|
|
|
|
/* cume_dist() is monotonically increasing */
|
|
|
|
|
req->monotonic = MONOTONICFUNC_INCREASING;
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
if (IsA(rawreq, SupportRequestOptimizeWindowClause))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestOptimizeWindowClause *req = (SupportRequestOptimizeWindowClause *) rawreq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* cume_dist() is unaffected by the frame options. Here we set the
|
|
|
|
|
* frame options to match what's done in row_number's support
|
|
|
|
|
* function. Using ROWS instead of RANGE (the default) saves the
|
|
|
|
|
* executor from having to check for peer rows.
|
|
|
|
|
*/
|
|
|
|
|
req->frameOptions = (FRAMEOPTION_NONDEFAULT |
|
|
|
|
|
FRAMEOPTION_ROWS |
|
|
|
|
|
FRAMEOPTION_START_UNBOUNDED_PRECEDING |
|
|
|
|
|
FRAMEOPTION_END_CURRENT_ROW);
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ntile
|
|
|
|
|
* compute an exact numeric value with scale 0 (zero),
|
|
|
|
|
* ranging from 1 (one) to n, per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_ntile(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
ntile_context *context;
|
|
|
|
|
|
|
|
|
|
context = (ntile_context *)
|
|
|
|
|
WinGetPartitionLocalMemory(winobj, sizeof(ntile_context));
|
|
|
|
|
|
|
|
|
|
if (context->ntile == 0)
|
|
|
|
|
{
|
|
|
|
|
/* first call */
|
|
|
|
|
int64 total;
|
|
|
|
|
int32 nbuckets;
|
|
|
|
|
bool isnull;
|
|
|
|
|
|
|
|
|
|
total = WinGetPartitionRowCount(winobj);
|
|
|
|
|
nbuckets = DatumGetInt32(WinGetFuncArgCurrent(winobj, 0, &isnull));
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* per spec: If NT is the null value, then the result is the null
|
|
|
|
|
* value.
|
|
|
|
|
*/
|
|
|
|
|
if (isnull)
|
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* per spec: If NT is less than or equal to 0 (zero), then an
|
|
|
|
|
* exception condition is raised.
|
|
|
|
|
*/
|
|
|
|
|
if (nbuckets <= 0)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_NTILE),
|
|
|
|
|
errmsg("argument of ntile must be greater than zero")));
|
|
|
|
|
|
|
|
|
|
context->ntile = 1;
|
|
|
|
|
context->rows_per_bucket = 0;
|
|
|
|
|
context->boundary = total / nbuckets;
|
|
|
|
|
if (context->boundary <= 0)
|
|
|
|
|
context->boundary = 1;
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* If the total number is not divisible, add 1 row to leading
|
|
|
|
|
* buckets.
|
|
|
|
|
*/
|
|
|
|
|
context->remainder = total % nbuckets;
|
|
|
|
|
if (context->remainder != 0)
|
|
|
|
|
context->boundary++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
context->rows_per_bucket++;
|
|
|
|
|
if (context->boundary < context->rows_per_bucket)
|
|
|
|
|
{
|
|
|
|
|
/* ntile up */
|
|
|
|
|
if (context->remainder != 0 && context->ntile == context->remainder)
|
|
|
|
|
{
|
|
|
|
|
context->remainder = 0;
|
|
|
|
|
context->boundary -= 1;
|
|
|
|
|
}
|
|
|
|
|
context->ntile += 1;
|
|
|
|
|
context->rows_per_bucket = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PG_RETURN_INT32(context->ntile);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
/*
|
|
|
|
|
* window_ntile_support
|
|
|
|
|
* prosupport function for window_ntile()
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_ntile_support(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
Node *rawreq = (Node *) PG_GETARG_POINTER(0);
|
|
|
|
|
|
|
|
|
|
if (IsA(rawreq, SupportRequestWFuncMonotonic))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestWFuncMonotonic *req = (SupportRequestWFuncMonotonic *) rawreq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ntile() is monotonically increasing as the number of buckets cannot
|
|
|
|
|
* change after the first call
|
|
|
|
|
*/
|
|
|
|
|
req->monotonic = MONOTONICFUNC_INCREASING;
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
Allow window functions to adjust their frameOptions
WindowFuncs such as row_number() don't care if it's called with ROWS
UNBOUNDED PRECEDING AND CURRENT ROW or with RANGE UNBOUNDED PRECEDING AND
CURRENT ROW. The latter is less efficient as the RANGE option requires
that the executor check for peer rows, so using the ROW option instead
would cause less overhead. Because RANGE is part of the default frame
options for WindowClauses, it means WindowAgg is, by default, working much
harder than it needs to for window functions where the ROWS / RANGE option
has no effect on the window function's result.
On a test query from the discussion thread, a performance improvement of
344% was seen by using ROWS instead of RANGE.
Here we add a new support function node type to allow support functions to
be called for window functions so that the most optimal version of the
frame options can be set. The planner has been adjusted so that the frame
options are changed only if all window functions sharing the same window
clause agree on what the optimized frame options are.
Here we give the ability for row_number(), rank(), dense_rank(),
percent_rank(), cume_dist() and ntile() to alter their WindowClause's
frameOptions.
Reviewed-by: Vik Fearing, Erwin Brandstetter, Zhihong Yu
Discussion: https://postgr.es/m/CAGHENJ7LBBszxS+SkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvohAKEtTXxq7Pc-ic2dKT8oZfbRKeEJP64M0B6+S88z+A@mail.gmail.com
3 years ago
|
|
|
if (IsA(rawreq, SupportRequestOptimizeWindowClause))
|
|
|
|
|
{
|
|
|
|
|
SupportRequestOptimizeWindowClause *req = (SupportRequestOptimizeWindowClause *) rawreq;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ntile() is unaffected by the frame options. Here we set the frame
|
|
|
|
|
* options to match what's done in row_number's support function.
|
|
|
|
|
* Using ROWS instead of RANGE (the default) saves the executor from
|
|
|
|
|
* having to check for peer rows.
|
|
|
|
|
*/
|
|
|
|
|
req->frameOptions = (FRAMEOPTION_NONDEFAULT |
|
|
|
|
|
FRAMEOPTION_ROWS |
|
|
|
|
|
FRAMEOPTION_START_UNBOUNDED_PRECEDING |
|
|
|
|
|
FRAMEOPTION_END_CURRENT_ROW);
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(req);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PG_RETURN_POINTER(NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* leadlag_common
|
|
|
|
|
* common operation of lead() and lag()
|
|
|
|
|
* For lead() forward is true, whereas for lag() it is false.
|
|
|
|
|
* withoffset indicates we have an offset second argument.
|
|
|
|
|
* withdefault indicates we have a default third argument.
|
|
|
|
|
*/
|
|
|
|
|
static Datum
|
|
|
|
|
leadlag_common(FunctionCallInfo fcinfo,
|
|
|
|
|
bool forward, bool withoffset, bool withdefault)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
int32 offset;
|
|
|
|
|
bool const_offset;
|
|
|
|
|
Datum result;
|
|
|
|
|
bool isnull;
|
|
|
|
|
bool isout;
|
|
|
|
|
|
|
|
|
|
if (withoffset)
|
|
|
|
|
{
|
|
|
|
|
offset = DatumGetInt32(WinGetFuncArgCurrent(winobj, 1, &isnull));
|
|
|
|
|
if (isnull)
|
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
const_offset = get_fn_expr_arg_stable(fcinfo->flinfo, 1);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
offset = 1;
|
|
|
|
|
const_offset = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
result = WinGetFuncArgInPartition(winobj, 0,
|
|
|
|
|
(forward ? offset : -offset),
|
|
|
|
|
WINDOW_SEEK_CURRENT,
|
|
|
|
|
const_offset,
|
|
|
|
|
&isnull, &isout);
|
|
|
|
|
|
|
|
|
|
if (isout)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* target row is out of the partition; supply default value if
|
|
|
|
|
* provided. otherwise it'll stay NULL
|
|
|
|
|
*/
|
|
|
|
|
if (withdefault)
|
|
|
|
|
result = WinGetFuncArgCurrent(winobj, 2, &isnull);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (isnull)
|
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* lag
|
|
|
|
|
* returns the value of VE evaluated on a row that is 1
|
|
|
|
|
* row before the current row within a partition,
|
|
|
|
|
* per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_lag(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
return leadlag_common(fcinfo, false, false, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* lag_with_offset
|
|
|
|
|
* returns the value of VE evaluated on a row that is OFFSET
|
|
|
|
|
* rows before the current row within a partition,
|
|
|
|
|
* per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_lag_with_offset(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
return leadlag_common(fcinfo, false, true, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* lag_with_offset_and_default
|
|
|
|
|
* same as lag_with_offset but accepts default value
|
|
|
|
|
* as its third argument.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_lag_with_offset_and_default(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
return leadlag_common(fcinfo, false, true, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* lead
|
|
|
|
|
* returns the value of VE evaluated on a row that is 1
|
|
|
|
|
* row after the current row within a partition,
|
|
|
|
|
* per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_lead(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
return leadlag_common(fcinfo, true, false, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* lead_with_offset
|
|
|
|
|
* returns the value of VE evaluated on a row that is OFFSET
|
|
|
|
|
* number of rows after the current row within a partition,
|
|
|
|
|
* per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_lead_with_offset(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
return leadlag_common(fcinfo, true, true, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* lead_with_offset_and_default
|
|
|
|
|
* same as lead_with_offset but accepts default value
|
|
|
|
|
* as its third argument.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_lead_with_offset_and_default(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
return leadlag_common(fcinfo, true, true, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* first_value
|
|
|
|
|
* return the value of VE evaluated on the first row of the
|
|
|
|
|
* window frame, per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_first_value(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
Datum result;
|
|
|
|
|
bool isnull;
|
|
|
|
|
|
|
|
|
|
result = WinGetFuncArgInFrame(winobj, 0,
|
|
|
|
|
0, WINDOW_SEEK_HEAD, true,
|
|
|
|
|
&isnull, NULL);
|
|
|
|
|
if (isnull)
|
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* last_value
|
|
|
|
|
* return the value of VE evaluated on the last row of the
|
|
|
|
|
* window frame, per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_last_value(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
Datum result;
|
|
|
|
|
bool isnull;
|
|
|
|
|
|
|
|
|
|
result = WinGetFuncArgInFrame(winobj, 0,
|
|
|
|
|
0, WINDOW_SEEK_TAIL, true,
|
|
|
|
|
&isnull, NULL);
|
|
|
|
|
if (isnull)
|
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* nth_value
|
|
|
|
|
* return the value of VE evaluated on the n-th row from the first
|
|
|
|
|
* row of the window frame, per spec.
|
|
|
|
|
*/
|
|
|
|
|
Datum
|
|
|
|
|
window_nth_value(PG_FUNCTION_ARGS)
|
|
|
|
|
{
|
|
|
|
|
WindowObject winobj = PG_WINDOW_OBJECT();
|
|
|
|
|
bool const_offset;
|
|
|
|
|
Datum result;
|
|
|
|
|
bool isnull;
|
|
|
|
|
int32 nth;
|
|
|
|
|
|
|
|
|
|
nth = DatumGetInt32(WinGetFuncArgCurrent(winobj, 1, &isnull));
|
|
|
|
|
if (isnull)
|
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
const_offset = get_fn_expr_arg_stable(fcinfo->flinfo, 1);
|
|
|
|
|
|
|
|
|
|
if (nth <= 0)
|
|
|
|
|
ereport(ERROR,
|
|
|
|
|
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_NTH_VALUE),
|
|
|
|
|
errmsg("argument of nth_value must be greater than zero")));
|
|
|
|
|
|
|
|
|
|
result = WinGetFuncArgInFrame(winobj, 0,
|
|
|
|
|
nth - 1, WINDOW_SEEK_HEAD, const_offset,
|
|
|
|
|
&isnull, NULL);
|
|
|
|
|
if (isnull)
|
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
|
|
|
|
|
PG_RETURN_DATUM(result);
|
|
|
|
|
}
|
