2001-06-25 23:11:45 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* selfuncs.h
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
* Selectivity functions for standard operators, and assorted
|
|
|
|
|
* infrastructure for selectivity and cost estimation.
|
2001-06-25 23:11:45 +02:00
|
|
|
*
|
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2001-06-25 23:11:45 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/utils/selfuncs.h
|
2001-06-25 23:11:45 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef SELFUNCS_H
|
|
|
|
|
#define SELFUNCS_H
|
|
|
|
|
|
2006-04-27 00:33:36 +02:00
|
|
|
#include "access/htup.h"
|
2019-08-19 21:51:38 +02:00
|
|
|
#include "fmgr.h"
|
2019-01-29 22:49:25 +01:00
|
|
|
#include "nodes/pathnodes.h"
|
2001-06-25 23:11:45 +02:00
|
|
|
|
|
|
|
|
|
2004-11-09 01:34:46 +01:00
|
|
|
/*
|
|
|
|
|
* Note: the default selectivity estimates are not chosen entirely at random.
|
|
|
|
|
* We want them to be small enough to ensure that indexscans will be used if
|
2014-05-06 18:12:18 +02:00
|
|
|
* available, for typical table densities of ~100 tuples/page. Thus, for
|
2004-11-09 01:34:46 +01:00
|
|
|
* example, 0.01 is not quite small enough, since that makes it appear that
|
|
|
|
|
* nearly all pages will be hit anyway. Also, since we sometimes estimate
|
|
|
|
|
* eqsel as 1/num_distinct, we probably want DEFAULT_NUM_DISTINCT to equal
|
|
|
|
|
* 1/DEFAULT_EQ_SEL.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* default selectivity estimate for equalities such as "A = b" */
|
|
|
|
|
#define DEFAULT_EQ_SEL 0.005
|
|
|
|
|
|
|
|
|
|
/* default selectivity estimate for inequalities such as "A < b" */
|
|
|
|
|
#define DEFAULT_INEQ_SEL 0.3333333333333333
|
|
|
|
|
|
|
|
|
|
/* default selectivity estimate for range inequalities "A > b AND A < c" */
|
2005-10-15 04:49:52 +02:00
|
|
|
#define DEFAULT_RANGE_INEQ_SEL 0.005
|
2004-11-09 01:34:46 +01:00
|
|
|
|
|
|
|
|
/* default selectivity estimate for pattern-match operators such as LIKE */
|
|
|
|
|
#define DEFAULT_MATCH_SEL 0.005
|
|
|
|
|
|
Improve selectivity estimation for assorted match-style operators.
Quite a few matching operators such as JSONB's @> used "contsel" and
"contjoinsel" as their selectivity estimators. That was a bad idea,
because (a) contsel is only a stub, yielding a fixed default estimate,
and (b) that default is 0.001, meaning we estimate these operators as
five times more selective than equality, which is surely pretty silly.
There's a good model for improving this in ltree's ltreeparentsel():
for any "var OP constant" query, we can try applying the operator
to all of the column's MCV and histogram values, taking the latter
as being a random sample of the non-MCV values. That code is
actually 100% generic, except for the question of exactly what
default selectivity ought to be plugged in when we don't have stats.
Hence, migrate the guts of ltreeparentsel() into the core code, provide
wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate
default estimate, and use those for the non-geometric operators that
formerly used contsel (mostly JSONB containment operators and tsquery
matching).
Also apply this code to some match-like operators in hstore, ltree, and
pg_trgm, including the former users of ltreeparentsel as well as ones
that improperly used contsel. Since commit 911e70207 just created new
versions of those extensions that we haven't released yet, we can sneak
this change into those new versions instead of having to create an
additional generation of update scripts.
Patch by me, reviewed by Alexey Bashtanov
Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
|
|
|
/* default selectivity estimate for other matching operators */
|
|
|
|
|
#define DEFAULT_MATCHING_SEL 0.010
|
|
|
|
|
|
2004-11-09 01:34:46 +01:00
|
|
|
/* default number of distinct values in a table */
|
|
|
|
|
#define DEFAULT_NUM_DISTINCT 200
|
|
|
|
|
|
|
|
|
|
/* default selectivity estimate for boolean and null test nodes */
|
|
|
|
|
#define DEFAULT_UNK_SEL 0.005
|
|
|
|
|
#define DEFAULT_NOT_UNK_SEL (1.0 - DEFAULT_UNK_SEL)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Clamp a computed probability estimate (which may suffer from roundoff or
|
|
|
|
|
* estimation errors) to valid range. Argument must be a float variable.
|
|
|
|
|
*/
|
|
|
|
|
#define CLAMP_PROBABILITY(p) \
|
|
|
|
|
do { \
|
|
|
|
|
if (p < 0.0) \
|
|
|
|
|
p = 0.0; \
|
|
|
|
|
else if (p > 1.0) \
|
|
|
|
|
p = 1.0; \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
|
2006-04-27 00:33:36 +02:00
|
|
|
/* Return data from examine_variable and friends */
|
2008-09-28 21:51:40 +02:00
|
|
|
typedef struct VariableStatData
|
2006-04-27 00:33:36 +02:00
|
|
|
{
|
|
|
|
|
Node *var; /* the Var or expression tree */
|
|
|
|
|
RelOptInfo *rel; /* Relation, or NULL if not identifiable */
|
|
|
|
|
HeapTuple statsTuple; /* pg_statistic tuple, or NULL if none */
|
|
|
|
|
/* NB: if statsTuple!=NULL, it must be freed when caller is done */
|
2008-09-28 21:51:40 +02:00
|
|
|
void (*freefunc) (HeapTuple tuple); /* how to free statsTuple */
|
2006-04-27 00:33:36 +02:00
|
|
|
Oid vartype; /* exposed type of expression */
|
Redesign get_attstatsslot()/free_attstatsslot() for more safety and speed.
The mess cleaned up in commit da0759600 is clear evidence that it's a
bug hazard to expect the caller of get_attstatsslot()/free_attstatsslot()
to provide the correct type OID for the array elements in the slot.
Moreover, we weren't even getting any performance benefit from that,
since get_attstatsslot() was extracting the real type OID from the array
anyway. So we ought to get rid of that requirement; indeed, it would
make more sense for get_attstatsslot() to pass back the type OID it found,
in case the caller isn't sure what to expect, which is likely in binary-
compatible-operator cases.
Another problem with the current implementation is that if the stats array
element type is pass-by-reference, we incur a palloc/memcpy/pfree cycle
for each element. That seemed acceptable when the code was written because
we were targeting O(10) array sizes --- but these days, stats arrays are
almost always bigger than that, sometimes much bigger. We can save a
significant number of cycles by doing one palloc/memcpy/pfree of the whole
array. Indeed, in the now-probably-common case where the array is toasted,
that happens anyway so this method is basically free. (Note: although the
catcache code will inline any out-of-line toasted values, it doesn't
decompress them. At the other end of the size range, it doesn't expand
short-header datums either. In either case, DatumGetArrayTypeP would have
to make a copy. We do end up using an extra array copy step if the element
type is pass-by-value and the array length is neither small enough for a
short header nor large enough to have suffered compression. But that
seems like a very acceptable price for winning in pass-by-ref cases.)
Hence, redesign to take these insights into account. While at it,
convert to an API in which we fill a struct rather than passing a bunch
of pointers to individual output arguments. That will make it less
painful if we ever want further expansion of what get_attstatsslot can
pass back.
It's certainly arguable that this is new development and not something to
push post-feature-freeze. However, I view it as primarily bug-proofing
and therefore something that's better to have sooner not later. Since
we aren't quite at beta phase yet, let's put it in.
Discussion: https://postgr.es/m/16364.1494520862@sss.pgh.pa.us
2017-05-13 21:14:39 +02:00
|
|
|
Oid atttype; /* actual type (after stripping relabel) */
|
|
|
|
|
int32 atttypmod; /* actual typmod (after stripping relabel) */
|
2012-02-16 23:33:28 +01:00
|
|
|
bool isunique; /* matches unique index or DISTINCT clause */
|
2017-05-05 18:18:48 +02:00
|
|
|
bool acl_ok; /* result of ACL check on table or column */
|
2006-04-27 00:33:36 +02:00
|
|
|
} VariableStatData;
|
|
|
|
|
|
|
|
|
|
#define ReleaseVariableStats(vardata) \
|
|
|
|
|
do { \
|
|
|
|
|
if (HeapTupleIsValid((vardata).statsTuple)) \
|
2017-09-07 18:06:23 +02:00
|
|
|
(vardata).freefunc((vardata).statsTuple); \
|
2006-04-27 00:33:36 +02:00
|
|
|
} while(0)
|
|
|
|
|
|
|
|
|
|
|
2016-03-24 03:01:35 +01:00
|
|
|
/*
|
|
|
|
|
* genericcostestimate is a general-purpose estimator that can be used for
|
|
|
|
|
* most index types. In some cases we use genericcostestimate as the base
|
|
|
|
|
* code and then incorporate additional index-type-specific knowledge in
|
|
|
|
|
* the type-specific calling function. To avoid code duplication, we make
|
|
|
|
|
* genericcostestimate return a number of intermediate values as well as
|
|
|
|
|
* its preliminary estimates of the output cost values. The GenericCosts
|
|
|
|
|
* struct includes all these values.
|
|
|
|
|
*
|
|
|
|
|
* Callers should initialize all fields of GenericCosts to zero. In addition,
|
|
|
|
|
* they can set numIndexTuples to some positive value if they have a better
|
|
|
|
|
* than default way of estimating the number of leaf index tuples visited.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct
|
|
|
|
|
{
|
|
|
|
|
/* These are the values the cost estimator must return to the planner */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
Cost indexStartupCost; /* index-related startup cost */
|
2016-03-24 03:01:35 +01:00
|
|
|
Cost indexTotalCost; /* total index-related scan cost */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
Selectivity indexSelectivity; /* selectivity of index */
|
|
|
|
|
double indexCorrelation; /* order correlation of index */
|
2016-03-24 03:01:35 +01:00
|
|
|
|
|
|
|
|
/* Intermediate values we obtain along the way */
|
|
|
|
|
double numIndexPages; /* number of leaf pages visited */
|
|
|
|
|
double numIndexTuples; /* number of leaf tuples visited */
|
|
|
|
|
double spc_random_page_cost; /* relevant random_page_cost value */
|
2019-08-13 06:53:41 +02:00
|
|
|
double num_sa_scans; /* # indexscans from ScalarArrayOpExprs */
|
2016-03-24 03:01:35 +01:00
|
|
|
} GenericCosts;
|
|
|
|
|
|
2008-09-28 21:51:40 +02:00
|
|
|
/* Hooks for plugins to get control when we ask for stats */
|
|
|
|
|
typedef bool (*get_relation_stats_hook_type) (PlannerInfo *root,
|
2017-06-21 20:39:04 +02:00
|
|
|
RangeTblEntry *rte,
|
|
|
|
|
AttrNumber attnum,
|
|
|
|
|
VariableStatData *vardata);
|
2008-09-28 21:51:40 +02:00
|
|
|
extern PGDLLIMPORT get_relation_stats_hook_type get_relation_stats_hook;
|
|
|
|
|
typedef bool (*get_index_stats_hook_type) (PlannerInfo *root,
|
2017-06-21 20:39:04 +02:00
|
|
|
Oid indexOid,
|
|
|
|
|
AttrNumber indexattnum,
|
|
|
|
|
VariableStatData *vardata);
|
2008-09-28 21:51:40 +02:00
|
|
|
extern PGDLLIMPORT get_index_stats_hook_type get_index_stats_hook;
|
|
|
|
|
|
2012-03-04 02:20:19 +01:00
|
|
|
/* Functions in selfuncs.c */
|
|
|
|
|
|
2006-04-27 02:46:59 +02:00
|
|
|
extern void examine_variable(PlannerInfo *root, Node *node, int varRelid,
|
2019-05-22 19:04:48 +02:00
|
|
|
VariableStatData *vardata);
|
2017-05-05 18:18:48 +02:00
|
|
|
extern bool statistic_proc_security_check(VariableStatData *vardata, Oid func_oid);
|
2006-04-27 02:46:59 +02:00
|
|
|
extern bool get_restriction_variable(PlannerInfo *root, List *args,
|
2019-05-22 19:04:48 +02:00
|
|
|
int varRelid,
|
|
|
|
|
VariableStatData *vardata, Node **other,
|
|
|
|
|
bool *varonleft);
|
2006-04-27 02:46:59 +02:00
|
|
|
extern void get_join_variables(PlannerInfo *root, List *args,
|
2019-05-22 19:04:48 +02:00
|
|
|
SpecialJoinInfo *sjinfo,
|
|
|
|
|
VariableStatData *vardata1,
|
|
|
|
|
VariableStatData *vardata2,
|
|
|
|
|
bool *join_is_reversed);
|
2011-09-04 21:41:49 +02:00
|
|
|
extern double get_variable_numdistinct(VariableStatData *vardata,
|
2019-05-22 19:04:48 +02:00
|
|
|
bool *isdefault);
|
Use query collation, not column's collation, while examining statistics.
Commit 5e0928005 changed the planner so that, instead of blindly using
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,
it would use the collation of the column whose statistics we're
considering. This was recognized as still being not quite the right
thing, but it seemed like a good incremental improvement. However,
shortly thereafter we introduced nondeterministic collations, and that
creates cases where operators can fail if they're passed the wrong
collation. We don't want planning to fail in cases where the query itself
would work, so this means that we *must* use the query's collation when
invoking operators for estimation purposes.
The only real problem this creates is in ineq_histogram_selectivity, where
the binary search might produce a garbage answer if we perform comparisons
using a different collation than the column's histogram is ordered with.
However, when the query's collation is significantly different from the
column's default collation, the estimate we previously generated would be
pretty irrelevant anyway; so it's not clear that this will result in
noticeably worse estimates in practice. (A follow-on patch will improve
this situation in HEAD, but it seems too invasive for back-patch.)
The patch requires changing the signatures of mcv_selectivity and allied
functions, which are exported and very possibly are used by extensions.
In HEAD, I just did that, but an API/ABI break of this sort isn't
acceptable in stable branches. Therefore, in v12 the patch introduces
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes
the old functions into wrappers that assume DEFAULT_COLLATION_OID should
be used. That does not match the prior behavior, but it should avoid risk
of failure in most cases. (In practice, I think most extension datatypes
aren't collation-aware, so the change probably doesn't matter to them.)
Per report from James Lucas. Back-patch to v12 where the problem was
introduced.
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com
2020-06-05 22:18:50 +02:00
|
|
|
extern double mcv_selectivity(VariableStatData *vardata,
|
|
|
|
|
FmgrInfo *opproc, Oid collation,
|
2019-05-22 19:04:48 +02:00
|
|
|
Datum constval, bool varonleft,
|
|
|
|
|
double *sumcommonp);
|
Use query collation, not column's collation, while examining statistics.
Commit 5e0928005 changed the planner so that, instead of blindly using
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,
it would use the collation of the column whose statistics we're
considering. This was recognized as still being not quite the right
thing, but it seemed like a good incremental improvement. However,
shortly thereafter we introduced nondeterministic collations, and that
creates cases where operators can fail if they're passed the wrong
collation. We don't want planning to fail in cases where the query itself
would work, so this means that we *must* use the query's collation when
invoking operators for estimation purposes.
The only real problem this creates is in ineq_histogram_selectivity, where
the binary search might produce a garbage answer if we perform comparisons
using a different collation than the column's histogram is ordered with.
However, when the query's collation is significantly different from the
column's default collation, the estimate we previously generated would be
pretty irrelevant anyway; so it's not clear that this will result in
noticeably worse estimates in practice. (A follow-on patch will improve
this situation in HEAD, but it seems too invasive for back-patch.)
The patch requires changing the signatures of mcv_selectivity and allied
functions, which are exported and very possibly are used by extensions.
In HEAD, I just did that, but an API/ABI break of this sort isn't
acceptable in stable branches. Therefore, in v12 the patch introduces
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes
the old functions into wrappers that assume DEFAULT_COLLATION_OID should
be used. That does not match the prior behavior, but it should avoid risk
of failure in most cases. (In practice, I think most extension datatypes
aren't collation-aware, so the change probably doesn't matter to them.)
Per report from James Lucas. Back-patch to v12 where the problem was
introduced.
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com
2020-06-05 22:18:50 +02:00
|
|
|
extern double histogram_selectivity(VariableStatData *vardata,
|
|
|
|
|
FmgrInfo *opproc, Oid collation,
|
2019-05-22 19:04:48 +02:00
|
|
|
Datum constval, bool varonleft,
|
|
|
|
|
int min_hist_size, int n_skip,
|
|
|
|
|
int *hist_size);
|
Use query collation, not column's collation, while examining statistics.
Commit 5e0928005 changed the planner so that, instead of blindly using
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,
it would use the collation of the column whose statistics we're
considering. This was recognized as still being not quite the right
thing, but it seemed like a good incremental improvement. However,
shortly thereafter we introduced nondeterministic collations, and that
creates cases where operators can fail if they're passed the wrong
collation. We don't want planning to fail in cases where the query itself
would work, so this means that we *must* use the query's collation when
invoking operators for estimation purposes.
The only real problem this creates is in ineq_histogram_selectivity, where
the binary search might produce a garbage answer if we perform comparisons
using a different collation than the column's histogram is ordered with.
However, when the query's collation is significantly different from the
column's default collation, the estimate we previously generated would be
pretty irrelevant anyway; so it's not clear that this will result in
noticeably worse estimates in practice. (A follow-on patch will improve
this situation in HEAD, but it seems too invasive for back-patch.)
The patch requires changing the signatures of mcv_selectivity and allied
functions, which are exported and very possibly are used by extensions.
In HEAD, I just did that, but an API/ABI break of this sort isn't
acceptable in stable branches. Therefore, in v12 the patch introduces
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes
the old functions into wrappers that assume DEFAULT_COLLATION_OID should
be used. That does not match the prior behavior, but it should avoid risk
of failure in most cases. (In practice, I think most extension datatypes
aren't collation-aware, so the change probably doesn't matter to them.)
Per report from James Lucas. Back-patch to v12 where the problem was
introduced.
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com
2020-06-05 22:18:50 +02:00
|
|
|
extern double generic_restriction_selectivity(PlannerInfo *root,
|
|
|
|
|
Oid oproid, Oid collation,
|
Improve selectivity estimation for assorted match-style operators.
Quite a few matching operators such as JSONB's @> used "contsel" and
"contjoinsel" as their selectivity estimators. That was a bad idea,
because (a) contsel is only a stub, yielding a fixed default estimate,
and (b) that default is 0.001, meaning we estimate these operators as
five times more selective than equality, which is surely pretty silly.
There's a good model for improving this in ltree's ltreeparentsel():
for any "var OP constant" query, we can try applying the operator
to all of the column's MCV and histogram values, taking the latter
as being a random sample of the non-MCV values. That code is
actually 100% generic, except for the question of exactly what
default selectivity ought to be plugged in when we don't have stats.
Hence, migrate the guts of ltreeparentsel() into the core code, provide
wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate
default estimate, and use those for the non-geometric operators that
formerly used contsel (mostly JSONB containment operators and tsquery
matching).
Also apply this code to some match-like operators in hstore, ltree, and
pg_trgm, including the former users of ltreeparentsel as well as ones
that improperly used contsel. Since commit 911e70207 just created new
versions of those extensions that we haven't released yet, we can sneak
this change into those new versions instead of having to create an
additional generation of update scripts.
Patch by me, reviewed by Alexey Bashtanov
Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
|
|
|
List *args, int varRelid,
|
|
|
|
|
double default_selectivity);
|
2019-02-14 16:51:59 +01:00
|
|
|
extern double ineq_histogram_selectivity(PlannerInfo *root,
|
2019-05-22 19:04:48 +02:00
|
|
|
VariableStatData *vardata,
|
|
|
|
|
FmgrInfo *opproc, bool isgt, bool iseq,
|
Use query collation, not column's collation, while examining statistics.
Commit 5e0928005 changed the planner so that, instead of blindly using
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,
it would use the collation of the column whose statistics we're
considering. This was recognized as still being not quite the right
thing, but it seemed like a good incremental improvement. However,
shortly thereafter we introduced nondeterministic collations, and that
creates cases where operators can fail if they're passed the wrong
collation. We don't want planning to fail in cases where the query itself
would work, so this means that we *must* use the query's collation when
invoking operators for estimation purposes.
The only real problem this creates is in ineq_histogram_selectivity, where
the binary search might produce a garbage answer if we perform comparisons
using a different collation than the column's histogram is ordered with.
However, when the query's collation is significantly different from the
column's default collation, the estimate we previously generated would be
pretty irrelevant anyway; so it's not clear that this will result in
noticeably worse estimates in practice. (A follow-on patch will improve
this situation in HEAD, but it seems too invasive for back-patch.)
The patch requires changing the signatures of mcv_selectivity and allied
functions, which are exported and very possibly are used by extensions.
In HEAD, I just did that, but an API/ABI break of this sort isn't
acceptable in stable branches. Therefore, in v12 the patch introduces
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes
the old functions into wrappers that assume DEFAULT_COLLATION_OID should
be used. That does not match the prior behavior, but it should avoid risk
of failure in most cases. (In practice, I think most extension datatypes
aren't collation-aware, so the change probably doesn't matter to them.)
Per report from James Lucas. Back-patch to v12 where the problem was
introduced.
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com
2020-06-05 22:18:50 +02:00
|
|
|
Oid collation,
|
2019-05-22 19:04:48 +02:00
|
|
|
Datum constval, Oid consttype);
|
Use query collation, not column's collation, while examining statistics.
Commit 5e0928005 changed the planner so that, instead of blindly using
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,
it would use the collation of the column whose statistics we're
considering. This was recognized as still being not quite the right
thing, but it seemed like a good incremental improvement. However,
shortly thereafter we introduced nondeterministic collations, and that
creates cases where operators can fail if they're passed the wrong
collation. We don't want planning to fail in cases where the query itself
would work, so this means that we *must* use the query's collation when
invoking operators for estimation purposes.
The only real problem this creates is in ineq_histogram_selectivity, where
the binary search might produce a garbage answer if we perform comparisons
using a different collation than the column's histogram is ordered with.
However, when the query's collation is significantly different from the
column's default collation, the estimate we previously generated would be
pretty irrelevant anyway; so it's not clear that this will result in
noticeably worse estimates in practice. (A follow-on patch will improve
this situation in HEAD, but it seems too invasive for back-patch.)
The patch requires changing the signatures of mcv_selectivity and allied
functions, which are exported and very possibly are used by extensions.
In HEAD, I just did that, but an API/ABI break of this sort isn't
acceptable in stable branches. Therefore, in v12 the patch introduces
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes
the old functions into wrappers that assume DEFAULT_COLLATION_OID should
be used. That does not match the prior behavior, but it should avoid risk
of failure in most cases. (In practice, I think most extension datatypes
aren't collation-aware, so the change probably doesn't matter to them.)
Per report from James Lucas. Back-patch to v12 where the problem was
introduced.
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com
2020-06-05 22:18:50 +02:00
|
|
|
extern double var_eq_const(VariableStatData *vardata,
|
|
|
|
|
Oid oproid, Oid collation,
|
2019-05-22 19:04:48 +02:00
|
|
|
Datum constval, bool constisnull,
|
|
|
|
|
bool varonleft, bool negate);
|
Use query collation, not column's collation, while examining statistics.
Commit 5e0928005 changed the planner so that, instead of blindly using
DEFAULT_COLLATION_OID when invoking operators for selectivity estimation,
it would use the collation of the column whose statistics we're
considering. This was recognized as still being not quite the right
thing, but it seemed like a good incremental improvement. However,
shortly thereafter we introduced nondeterministic collations, and that
creates cases where operators can fail if they're passed the wrong
collation. We don't want planning to fail in cases where the query itself
would work, so this means that we *must* use the query's collation when
invoking operators for estimation purposes.
The only real problem this creates is in ineq_histogram_selectivity, where
the binary search might produce a garbage answer if we perform comparisons
using a different collation than the column's histogram is ordered with.
However, when the query's collation is significantly different from the
column's default collation, the estimate we previously generated would be
pretty irrelevant anyway; so it's not clear that this will result in
noticeably worse estimates in practice. (A follow-on patch will improve
this situation in HEAD, but it seems too invasive for back-patch.)
The patch requires changing the signatures of mcv_selectivity and allied
functions, which are exported and very possibly are used by extensions.
In HEAD, I just did that, but an API/ABI break of this sort isn't
acceptable in stable branches. Therefore, in v12 the patch introduces
"mcv_selectivity_ext" and so on, with signatures matching HEAD, and makes
the old functions into wrappers that assume DEFAULT_COLLATION_OID should
be used. That does not match the prior behavior, but it should avoid risk
of failure in most cases. (In practice, I think most extension datatypes
aren't collation-aware, so the change probably doesn't matter to them.)
Per report from James Lucas. Back-patch to v12 where the problem was
introduced.
Discussion: https://postgr.es/m/CAAFmbbOvfi=wMM=3qRsPunBSLb8BFREno2oOzSBS=mzfLPKABw@mail.gmail.com
2020-06-05 22:18:50 +02:00
|
|
|
extern double var_eq_non_const(VariableStatData *vardata,
|
|
|
|
|
Oid oproid, Oid collation,
|
2019-05-22 19:04:48 +02:00
|
|
|
Node *other,
|
|
|
|
|
bool varonleft, bool negate);
|
2001-06-25 23:11:45 +02:00
|
|
|
|
Allow planner to use expression-index stats for function calls in WHERE.
Previously, a function call appearing at the top level of WHERE had a
hard-wired selectivity estimate of 0.3333333, a kludge conveniently dated
in the source code itself to July 1992. The expectation at the time was
that somebody would soon implement estimator support functions analogous
to those for operators; but no such code has appeared, nor does it seem
likely to in the near future. We do have an alternative solution though,
at least for immutable functions on single relations: creating an
expression index on the function call will allow ANALYZE to gather stats
about the function's selectivity. But the code in clause_selectivity()
failed to make use of such data even if it exists.
Refactor so that that will happen. I chose to make it try this technique
for any clause type for which clause_selectivity() doesn't have a special
case, not just functions. To avoid adding unnecessary overhead in the
common case where we don't learn anything new, make selfuncs.c provide an
API that hooks directly to examine_variable() and then var_eq_const(),
rather than the previous coding which laboriously constructed an OpExpr
only so that it could be expensively deconstructed again.
I preserved the behavior that the default estimate for a function call
is 0.3333333. (For any other expression node type, it's 0.5, as before.)
I had originally thought to make the default be 0.5 across the board, but
changing a default estimate that's survived for twenty-three years seems
like something not to do without a lot more testing than I care to put
into it right now.
Per a complaint from Jehan-Guillaume de Rorthais. Back-patch into 9.5,
but not further, at least for the moment.
2015-09-25 00:35:46 +02:00
|
|
|
extern Selectivity boolvarsel(PlannerInfo *root, Node *arg, int varRelid);
|
2005-06-06 00:32:58 +02:00
|
|
|
extern Selectivity booltestsel(PlannerInfo *root, BoolTestType booltesttype,
|
2019-05-22 19:04:48 +02:00
|
|
|
Node *arg, int varRelid,
|
|
|
|
|
JoinType jointype, SpecialJoinInfo *sjinfo);
|
2005-06-06 00:32:58 +02:00
|
|
|
extern Selectivity nulltestsel(PlannerInfo *root, NullTestType nulltesttype,
|
2019-05-22 19:04:48 +02:00
|
|
|
Node *arg, int varRelid,
|
|
|
|
|
JoinType jointype, SpecialJoinInfo *sjinfo);
|
2005-11-25 20:47:50 +01:00
|
|
|
extern Selectivity scalararraysel(PlannerInfo *root,
|
2019-05-22 19:04:48 +02:00
|
|
|
ScalarArrayOpExpr *clause,
|
|
|
|
|
bool is_join_clause,
|
|
|
|
|
int varRelid, JoinType jointype, SpecialJoinInfo *sjinfo);
|
2006-07-02 00:07:23 +02:00
|
|
|
extern int estimate_array_length(Node *arrayexpr);
|
2006-01-14 01:14:12 +01:00
|
|
|
extern Selectivity rowcomparesel(PlannerInfo *root,
|
2019-05-22 19:04:48 +02:00
|
|
|
RowCompareExpr *clause,
|
|
|
|
|
int varRelid, JoinType jointype, SpecialJoinInfo *sjinfo);
|
2002-03-01 05:09:28 +01:00
|
|
|
|
2005-06-06 00:32:58 +02:00
|
|
|
extern void mergejoinscansel(PlannerInfo *root, Node *clause,
|
2019-05-22 19:04:48 +02:00
|
|
|
Oid opfamily, int strategy, bool nulls_first,
|
|
|
|
|
Selectivity *leftstart, Selectivity *leftend,
|
|
|
|
|
Selectivity *rightstart, Selectivity *rightend);
|
2001-06-25 23:11:45 +02:00
|
|
|
|
2005-06-06 00:32:58 +02:00
|
|
|
extern double estimate_num_groups(PlannerInfo *root, List *groupExprs,
|
2019-05-22 19:04:48 +02:00
|
|
|
double input_rows, List **pgset);
|
2002-11-20 00:22:00 +01:00
|
|
|
|
Avoid out-of-memory in a hash join with many duplicate inner keys.
The executor is capable of splitting buckets during a hash join if
too much memory is being used by a small number of buckets. However,
this only helps if a bucket's population is actually divisible; if
all the hash keys are alike, the tuples still end up in the same
new bucket. This can result in an OOM failure if there are enough
inner keys with identical hash values. The planner's cost estimates
will bias it against choosing a hash join in such situations, but not
by so much that it will never do so. To mitigate the OOM hazard,
explicitly estimate the hash bucket space needed by just the inner
side's most common value, and if that would exceed work_mem then
add disable_cost to the hash cost estimate.
This approach doesn't account for the possibility that two or more
common values would share the same hash value. On the other hand,
work_mem is normally a fairly conservative bound, so that eating
two or more times that much space is probably not going to kill us.
If we have no stats about the inner side, ignore this consideration.
There was some discussion of making a conservative assumption, but that
would effectively result in disabling hash join whenever we lack stats,
which seems like an overreaction given how seldom the problem manifests
in the field.
Per a complaint from David Hinkle. Although this could be viewed
as a bug fix, the lack of similar complaints weighs against back-
patching; indeed we waited for v11 because it seemed already rather
late in the v10 cycle to be making plan choice changes like this one.
Discussion: https://postgr.es/m/32013.1487271761@sss.pgh.pa.us
2017-08-15 20:05:46 +02:00
|
|
|
extern void estimate_hash_bucket_stats(PlannerInfo *root,
|
2019-05-22 19:04:48 +02:00
|
|
|
Node *hashkey, double nbuckets,
|
|
|
|
|
Selectivity *mcv_freq,
|
|
|
|
|
Selectivity *bucketsize_frac);
|
2019-02-21 20:59:02 +01:00
|
|
|
extern double estimate_hashagg_tablesize(Path *path,
|
2019-05-22 19:04:48 +02:00
|
|
|
const AggClauseCosts *agg_costs,
|
|
|
|
|
double dNumGroups);
|
2004-02-17 01:52:53 +01:00
|
|
|
|
2019-02-15 19:05:19 +01:00
|
|
|
extern List *get_quals_from_indexclauses(List *indexclauses);
|
|
|
|
|
extern Cost index_other_operands_eval_cost(PlannerInfo *root,
|
2019-05-22 19:04:48 +02:00
|
|
|
List *indexquals);
|
2019-02-15 19:05:19 +01:00
|
|
|
extern List *add_predicate_to_index_quals(IndexOptInfo *index,
|
2019-05-22 19:04:48 +02:00
|
|
|
List *indexQuals);
|
2016-03-24 03:01:35 +01:00
|
|
|
extern void genericcostestimate(PlannerInfo *root, IndexPath *path,
|
2019-05-22 19:04:48 +02:00
|
|
|
double loop_count,
|
|
|
|
|
GenericCosts *costs);
|
2016-03-24 03:01:35 +01:00
|
|
|
|
2012-03-04 02:20:19 +01:00
|
|
|
/* Functions in array_selfuncs.c */
|
|
|
|
|
|
|
|
|
|
extern Selectivity scalararraysel_containment(PlannerInfo *root,
|
2019-05-22 19:04:48 +02:00
|
|
|
Node *leftop, Node *rightop,
|
|
|
|
|
Oid elemtype, bool isEquality, bool useOr,
|
|
|
|
|
int varRelid);
|
2012-03-04 02:20:19 +01:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* SELFUNCS_H */
|
