| blob | 08fa6774d9c1839e00a38b1b6b5f93264d4dbf1a |
1 /*-------------------------------------------------------------------------
2 *
3 * selfuncs.c
4 * Selectivity functions and index cost estimation functions for
5 * standard operators and index access methods.
6 *
7 * Selectivity routines are registered in the pg_operator catalog
8 * in the "oprrest" and "oprjoin" attributes.
9 *
10 * Index cost functions are located via the index AM's API struct,
11 * which is obtained from the handler function registered in pg_am.
12 *
13 * Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
14 * Portions Copyright (c) 1994, Regents of the University of California
15 *
16 *
17 * IDENTIFICATION
18 * src/backend/utils/adt/selfuncs.c
19 *
20 *-------------------------------------------------------------------------
21 */
23 /*----------
24 * Operator selectivity estimation functions are called to estimate the
25 * selectivity of WHERE clauses whose top-level operator is their operator.
26 * We divide the problem into two cases:
27 * Restriction clause estimation: the clause involves vars of just
28 * one relation.
29 * Join clause estimation: the clause involves vars of multiple rels.
30 * Join selectivity estimation is far more difficult and usually less accurate
31 * than restriction estimation.
32 *
33 * When dealing with the inner scan of a nestloop join, we consider the
34 * join's joinclauses as restriction clauses for the inner relation, and
35 * treat vars of the outer relation as parameters (a/k/a constants of unknown
36 * values). So, restriction estimators need to be able to accept an argument
37 * telling which relation is to be treated as the variable.
38 *
39 * The call convention for a restriction estimator (oprrest function) is
40 *
41 * Selectivity oprrest (PlannerInfo *root,
42 * Oid operator,
43 * List *args,
44 * int varRelid);
45 *
46 * root: general information about the query (rtable and RelOptInfo lists
47 * are particularly important for the estimator).
48 * operator: OID of the specific operator in question.
49 * args: argument list from the operator clause.
50 * varRelid: if not zero, the relid (rtable index) of the relation to
51 * be treated as the variable relation. May be zero if the args list
52 * is known to contain vars of only one relation.
53 *
54 * This is represented at the SQL level (in pg_proc) as
55 *
56 * float8 oprrest (internal, oid, internal, int4);
57 *
58 * The result is a selectivity, that is, a fraction (0 to 1) of the rows
59 * of the relation that are expected to produce a TRUE result for the
60 * given operator.
61 *
62 * The call convention for a join estimator (oprjoin function) is similar
63 * except that varRelid is not needed, and instead join information is
64 * supplied:
65 *
66 * Selectivity oprjoin (PlannerInfo *root,
67 * Oid operator,
68 * List *args,
69 * JoinType jointype,
70 * SpecialJoinInfo *sjinfo);
71 *
72 * float8 oprjoin (internal, oid, internal, int2, internal);
73 *
74 * (Before Postgres 8.4, join estimators had only the first four of these
75 * parameters. That signature is still allowed, but deprecated.) The
76 * relationship between jointype and sjinfo is explained in the comments for
77 * clause_selectivity() --- the short version is that jointype is usually
78 * best ignored in favor of examining sjinfo.
79 *
80 * Join selectivity for regular inner and outer joins is defined as the
81 * fraction (0 to 1) of the cross product of the relations that is expected
82 * to produce a TRUE result for the given operator. For both semi and anti
83 * joins, however, the selectivity is defined as the fraction of the left-hand
84 * side relation's rows that are expected to have a match (ie, at least one
85 * row with a TRUE result) in the right-hand side.
86 *
87 * For both oprrest and oprjoin functions, the operator's input collation OID
88 * (if any) is passed using the standard fmgr mechanism, so that the estimator
89 * function can fetch it with PG_GET_COLLATION(). Note, however, that all
90 * statistics in pg_statistic are currently built using the relevant column's
91 * collation.
92 *----------
93 */
97 #include <ctype.h>
98 #include <math.h>
144 #define DEFAULT_PAGE_CPU_MULTIPLIER 50.0
146 /* Hooks for plugins to get control when we ask for stats */
181 Datum lobound,
183 Datum hibound,
207 Relation indexRel,
208 ScanDirection indexscandir,
209 ScanKey scankeys,
210 int16 typLen,
213 MemoryContext outercontext,
218 /*
219 * eqsel - Selectivity of "=" for any data types.
220 *
221 * Note: this routine is also used to estimate selectivity for some
222 * operators that are not "=" but have comparable selectivity behavior,
223 * such as "~=" (geometric approximate-match). Even for "=", we must
224 * keep in mind that the left and right datatypes may differ.
225 */
226 Datum
228 {
230 }
232 /*
233 * Common code for eqsel() and neqsel()
234 */
235 static double
237 {
243 VariableStatData vardata;
248 /*
249 * When asked about <>, we do the estimation using the corresponding =
250 * operator, then convert to <> via "1.0 - eq_selectivity - nullfrac".
251 */
253 {
256 {
257 /* Use default selectivity (should we raise an error instead?) */
259 }
260 }
262 /*
263 * If expression is not variable = something or something = variable, then
264 * punt and return a default estimate.
265 */
270 /*
271 * We can do a lot better if the something is a constant. (Note: the
272 * Const might result from estimation rather than being a simple constant
273 * in the query.)
274 */
280 else
287 }
289 /*
290 * var_eq_const --- eqsel for var = const case
291 *
292 * This is exported so that some other estimation functions can use it.
293 */
294 double
298 {
302 Oid opfuncoid;
304 /*
305 * If the constant is NULL, assume operator is strict and return zero, ie,
306 * operator will never return TRUE. (It's zero even for a negator op.)
307 */
311 /*
312 * Grab the nullfrac for use below. Note we allow use of nullfrac
313 * regardless of security check.
314 */
316 {
317 Form_pg_statistic stats;
321 }
323 /*
324 * If we matched the var to a unique index or DISTINCT clause, assume
325 * there is exactly one match regardless of anything else. (This is
326 * slightly bogus, since the index or clause's equality operator might be
327 * different from ours, but it's much more likely to be right than
328 * ignoring the information.)
329 */
331 {
333 }
337 {
338 AttStatsSlot sslot;
342 /*
343 * Is the constant "=" to any of the column's most common values?
344 * (Although the given operator may not really be "=", we will assume
345 * that seeing whether it returns TRUE is an appropriate test. If you
346 * don't like this, maybe you shouldn't be using eqsel for your
347 * operator...)
348 */
352 {
354 FmgrInfo eqproc;
358 /*
359 * Save a few cycles by setting up the fcinfo struct just once.
360 * Using FunctionCallInvoke directly also avoids failure if the
361 * eqproc returns NULL, though really equality functions should
362 * never do that.
363 */
368 /* be careful to apply operator right way 'round */
371 else
375 {
376 Datum fresult;
380 else
385 {
388 }
389 }
390 }
391 else
392 {
393 /* no most-common-value info available */
395 }
398 {
399 /*
400 * Constant is "=" to this common value. We know selectivity
401 * exactly (or as exactly as ANALYZE could calculate it, anyway).
402 */
404 }
405 else
406 {
407 /*
408 * Comparison is against a constant that is neither NULL nor any
409 * of the common values. Its selectivity cannot be more than
410 * this:
411 */
420 /*
421 * and in fact it's probably a good deal less. We approximate that
422 * all the not-common values share this remaining fraction
423 * equally, so we divide by the number of other distinct values.
424 */
430 /*
431 * Another cross-check: selectivity shouldn't be estimated as more
432 * than the least common "most common value".
433 */
436 }
439 }
440 else
441 {
442 /*
443 * No ANALYZE stats available, so make a guess using estimated number
444 * of distinct values and assuming they are equally common. (The guess
445 * is unlikely to be very good, but we do know a few special cases.)
446 */
448 }
450 /* now adjust if we wanted <> rather than = */
454 /* result should be in range, but make sure... */
458 }
460 /*
461 * var_eq_non_const --- eqsel for var = something-other-than-const case
462 *
463 * This is exported so that some other estimation functions can use it.
464 */
465 double
469 {
474 /*
475 * Grab the nullfrac for use below.
476 */
478 {
479 Form_pg_statistic stats;
483 }
485 /*
486 * If we matched the var to a unique index or DISTINCT clause, assume
487 * there is exactly one match regardless of anything else. (This is
488 * slightly bogus, since the index or clause's equality operator might be
489 * different from ours, but it's much more likely to be right than
490 * ignoring the information.)
491 */
493 {
495 }
497 {
499 AttStatsSlot sslot;
501 /*
502 * Search is for a value that we do not know a priori, but we will
503 * assume it is not NULL. Estimate the selectivity as non-null
504 * fraction divided by number of distinct values, so that we get a
505 * result averaged over all possible values whether common or
506 * uncommon. (Essentially, we are assuming that the not-yet-known
507 * comparison value is equally likely to be any of the possible
508 * values, regardless of their frequency in the table. Is that a good
509 * idea?)
510 */
516 /*
517 * Cross-check: selectivity should never be estimated as more than the
518 * most common value's.
519 */
522 ATTSTATSSLOT_NUMBERS))
523 {
527 }
528 }
529 else
530 {
531 /*
532 * No ANALYZE stats available, so make a guess using estimated number
533 * of distinct values and assuming they are equally common. (The guess
534 * is unlikely to be very good, but we do know a few special cases.)
535 */
537 }
539 /* now adjust if we wanted <> rather than = */
543 /* result should be in range, but make sure... */
547 }
549 /*
550 * neqsel - Selectivity of "!=" for any data types.
551 *
552 * This routine is also used for some operators that are not "!="
553 * but have comparable selectivity behavior. See above comments
554 * for eqsel().
555 */
556 Datum
558 {
560 }
562 /*
563 * scalarineqsel - Selectivity of "<", "<=", ">", ">=" for scalars.
564 *
565 * This is the guts of scalarltsel/scalarlesel/scalargtsel/scalargesel.
566 * The isgt and iseq flags distinguish which of the four cases apply.
567 *
568 * The caller has commuted the clause, if necessary, so that we can treat
569 * the variable as being on the left. The caller must also make sure that
570 * the other side of the clause is a non-null Const, and dissect that into
571 * a value and datatype. (This definition simplifies some callers that
572 * want to estimate against a computed value instead of a Const node.)
573 *
574 * This routine works for any datatype (or pair of datatypes) known to
575 * convert_to_scalar(). If it is applied to some other datatype,
576 * it will return an approximate estimate based on assuming that the constant
577 * value falls in the middle of the bin identified by binary search.
578 */
579 static double
581 Oid collation,
583 {
584 Form_pg_statistic stats;
585 FmgrInfo opproc;
587 hist_selec,
588 sumcommon;
592 {
593 /*
594 * No stats are available. Typically this means we have to fall back
595 * on the default estimate; but if the variable is CTID then we can
596 * make an estimate based on comparing the constant to the table size.
597 */
600 {
601 ItemPointer itemptr;
605 /*
606 * If the relation's empty, we're going to include all of it.
607 * (This is mostly to avoid divide-by-zero below.)
608 */
615 /*
616 * Determine the average number of tuples per page (density).
617 *
618 * Since the last page will, on average, be only half full, we can
619 * estimate it to have half as many tuples as earlier pages. So
620 * give it half the weight of a regular page.
621 */
624 /* If target is the last page, use half the density. */
628 /*
629 * Using the average tuples per page, calculate how far into the
630 * page the itemptr is likely to be and adjust block accordingly,
631 * by adding that fraction of a whole block (but never more than a
632 * whole block, no matter how high the itemptr's offset is). Here
633 * we are ignoring the possibility of dead-tuple line pointers,
634 * which is fairly bogus, but we lack the info to do better.
635 */
637 {
641 }
643 /*
644 * Convert relative block number to selectivity. Again, the last
645 * page has only half weight.
646 */
649 /*
650 * The calculation so far gave us a selectivity for the "<=" case.
651 * We'll have one fewer tuple for "<" and one additional tuple for
652 * ">=", the latter of which we'll reverse the selectivity for
653 * below, so we can simply subtract one tuple for both cases. The
654 * cases that need this adjustment can be identified by iseq being
655 * equal to isgt.
656 */
660 /* Finally, reverse the selectivity for the ">", ">=" cases. */
666 }
668 /* no stats available, so default result */
670 }
675 /*
676 * If we have most-common-values info, add up the fractions of the MCV
677 * entries that satisfy MCV OP CONST. These fractions contribute directly
678 * to the result selectivity. Also add up the total fraction represented
679 * by MCV entries.
680 */
684 /*
685 * If there is a histogram, determine which bin the constant falls in, and
686 * compute the resulting contribution to selectivity.
687 */
690 collation,
693 /*
694 * Now merge the results from the MCV and histogram calculations,
695 * realizing that the histogram covers only the non-null values that are
696 * not listed in MCV.
697 */
702 else
703 {
704 /*
705 * If no histogram but there are values not accounted for by MCV,
706 * arbitrarily assume half of them will match.
707 */
709 }
713 /* result should be in range, but make sure... */
717 }
719 /*
720 * mcv_selectivity - Examine the MCV list for selectivity estimates
721 *
722 * Determine the fraction of the variable's MCV population that satisfies
723 * the predicate (VAR OP CONST), or (CONST OP VAR) if !varonleft. Also
724 * compute the fraction of the total column population represented by the MCV
725 * list. This code will work for any boolean-returning predicate operator.
726 *
727 * The function result is the MCV selectivity, and the fraction of the
728 * total population is returned into *sumcommonp. Zeroes are returned
729 * if there is no MCV list.
730 */
731 double
735 {
737 sumcommon;
738 AttStatsSlot sslot;
749 {
752 /*
753 * We invoke the opproc "by hand" so that we won't fail on NULL
754 * results. Such cases won't arise for normal comparison functions,
755 * but generic_restriction_selectivity could perhaps be used with
756 * operators that can return NULL. A small side benefit is to not
757 * need to re-initialize the fcinfo struct from scratch each time.
758 */
763 /* be careful to apply operator right way 'round */
766 else
770 {
771 Datum fresult;
775 else
782 }
784 }
788 }
790 /*
791 * histogram_selectivity - Examine the histogram for selectivity estimates
792 *
793 * Determine the fraction of the variable's histogram entries that satisfy
794 * the predicate (VAR OP CONST), or (CONST OP VAR) if !varonleft.
795 *
796 * This code will work for any boolean-returning predicate operator, whether
797 * or not it has anything to do with the histogram sort operator. We are
798 * essentially using the histogram just as a representative sample. However,
799 * small histograms are unlikely to be all that representative, so the caller
800 * should be prepared to fall back on some other estimation approach when the
801 * histogram is missing or very small. It may also be prudent to combine this
802 * approach with another one when the histogram is small.
803 *
804 * If the actual histogram size is not at least min_hist_size, we won't bother
805 * to do the calculation at all. Also, if the n_skip parameter is > 0, we
806 * ignore the first and last n_skip histogram elements, on the grounds that
807 * they are outliers and hence not very representative. Typical values for
808 * these parameters are 10 and 1.
809 *
810 * The function result is the selectivity, or -1 if there is no histogram
811 * or it's smaller than min_hist_size.
812 *
813 * The output parameter *hist_size receives the actual histogram size,
814 * or zero if no histogram. Callers may use this number to decide how
815 * much faith to put in the function result.
816 *
817 * Note that the result disregards both the most-common-values (if any) and
818 * null entries. The caller is expected to combine this result with
819 * statistics for those portions of the column population. It may also be
820 * prudent to clamp the result range, ie, disbelieve exact 0 or 1 outputs.
821 */
822 double
828 {
830 AttStatsSlot sslot;
832 /* check sanity of parameters */
840 ATTSTATSSLOT_VALUES))
841 {
844 {
849 /*
850 * We invoke the opproc "by hand" so that we won't fail on NULL
851 * results. Such cases won't arise for normal comparison
852 * functions, but generic_restriction_selectivity could perhaps be
853 * used with operators that can return NULL. A small side benefit
854 * is to not need to re-initialize the fcinfo struct from scratch
855 * each time.
856 */
861 /* be careful to apply operator right way 'round */
864 else
868 {
869 Datum fresult;
873 else
878 nmatch++;
879 }
881 }
882 else
885 }
886 else
887 {
890 }
893 }
895 /*
896 * generic_restriction_selectivity - Selectivity for almost anything
897 *
898 * This function estimates selectivity for operators that we don't have any
899 * special knowledge about, but are on data types that we collect standard
900 * MCV and/or histogram statistics for. (Additional assumptions are that
901 * the operator is strict and immutable, or at least stable.)
902 *
903 * If we have "VAR OP CONST" or "CONST OP VAR", selectivity is estimated by
904 * applying the operator to each element of the column's MCV and/or histogram
905 * stats, and merging the results using the assumption that the histogram is
906 * a reasonable random sample of the column's non-MCV population. Note that
907 * if the operator's semantics are related to the histogram ordering, this
908 * might not be such a great assumption; other functions such as
909 * scalarineqsel() are probably a better match in such cases.
910 *
911 * Otherwise, fall back to the default selectivity provided by the caller.
912 */
913 double
917 {
919 VariableStatData vardata;
923 /*
924 * If expression is not variable OP something or something OP variable,
925 * then punt and return the default estimate.
926 */
931 /*
932 * If the something is a NULL constant, assume operator is strict and
933 * return zero, ie, operator will never return TRUE.
934 */
937 {
940 }
943 {
944 /* Variable is being compared to a known non-null constant */
946 FmgrInfo opproc;
954 /*
955 * Calculate the selectivity for the column's most common values.
956 */
961 /*
962 * If the histogram is large enough, see what fraction of it matches
963 * the query, and assume that's representative of the non-MCV
964 * population. Otherwise use the default selectivity for the non-MCV
965 * population.
966 */
971 {
972 /* Nope, fall back on default */
974 }
976 {
977 /*
978 * For histogram sizes from 10 to 100, we combine the histogram
979 * and default selectivities, putting increasingly more trust in
980 * the histogram for larger sizes.
981 */
986 }
988 /* In any case, don't believe extremely small or large estimates. */
994 /* Don't forget to account for nulls. */
997 else
1000 /*
1001 * Now merge the results from the MCV and histogram calculations,
1002 * realizing that the histogram covers only the non-null values that
1003 * are not listed in MCV.
1004 */
1007 }
1008 else
1009 {
1010 /* Comparison value is not constant, so we can't do anything */
1012 }
1016 /* result should be in range, but make sure... */
1020 }
1022 /*
1023 * ineq_histogram_selectivity - Examine the histogram for scalarineqsel
1024 *
1025 * Determine the fraction of the variable's histogram population that
1026 * satisfies the inequality condition, ie, VAR < (or <=, >, >=) CONST.
1027 * The isgt and iseq flags distinguish which of the four cases apply.
1028 *
1029 * While opproc could be looked up from the operator OID, common callers
1030 * also need to call it separately, so we make the caller pass both.
1031 *
1032 * Returns -1 if there is no histogram (valid results will always be >= 0).
1033 *
1034 * Note that the result disregards both the most-common-values (if any) and
1035 * null entries. The caller is expected to combine this result with
1036 * statistics for those portions of the column population.
1037 *
1038 * This is exported so that some other estimation functions can use it.
1039 */
1040 double
1044 Oid collation,
1046 {
1048 AttStatsSlot sslot;
1052 /*
1053 * Someday, ANALYZE might store more than one histogram per rel/att,
1054 * corresponding to more than one possible sort ordering defined for the
1055 * column type. Right now, we know there is only one, so just grab it and
1056 * see if it matches the query.
1057 *
1058 * Note that we can't use opoid as search argument; the staop appearing in
1059 * pg_statistic will be for the relevant '<' operator, but what we have
1060 * might be some other inequality operator such as '>='. (Even if opoid
1061 * is a '<' operator, it could be cross-type.) Hence we must use
1062 * comparison_ops_are_compatible() to see if the operators match.
1063 */
1068 ATTSTATSSLOT_VALUES))
1069 {
1073 {
1074 /*
1075 * Use binary search to find the desired location, namely the
1076 * right end of the histogram bin containing the comparison value,
1077 * which is the leftmost entry for which the comparison operator
1078 * succeeds (if isgt) or fails (if !isgt).
1079 *
1080 * In this loop, we pay no attention to whether the operator iseq
1081 * or not; that detail will be mopped up below. (We cannot tell,
1082 * anyway, whether the operator thinks the values are equal.)
1083 *
1084 * If the binary search accesses the first or last histogram
1085 * entry, we try to replace that endpoint with the true column min
1086 * or max as found by get_actual_variable_range(). This
1087 * ameliorates misestimates when the min or max is moving as a
1088 * result of changes since the last ANALYZE. Note that this could
1089 * result in effectively including MCVs into the histogram that
1090 * weren't there before, but we don't try to correct for that.
1091 */
1097 /*
1098 * If there are only two histogram entries, we'll want up-to-date
1099 * values for both. (If there are more than two, we need at most
1100 * one of them to be updated, so we deal with that within the
1101 * loop.)
1102 */
1105 vardata,
1107 collation,
1112 {
1116 /*
1117 * If we find ourselves about to compare to the first or last
1118 * histogram entry, first try to replace it with the actual
1119 * current min or max (unless we already did so above).
1120 */
1123 vardata,
1125 collation,
1127 NULL);
1130 vardata,
1132 collation,
1133 NULL,
1137 collation,
1139 constval));
1144 else
1146 }
1149 {
1150 /*
1151 * Constant is below lower histogram boundary. More
1152 * precisely, we have found that no entry in the histogram
1153 * satisfies the inequality clause (if !isgt) or they all do
1154 * (if isgt). We estimate that that's true of the entire
1155 * table, so set histfrac to 0.0 (which we'll flip to 1.0
1156 * below, if isgt).
1157 */
1159 }
1161 {
1162 /*
1163 * Inverse case: constant is above upper histogram boundary.
1164 */
1166 }
1167 else
1168 {
1169 /* We have values[i-1] <= constant <= values[i]. */
1173 high,
1174 low;
1177 /*
1178 * In the cases where we'll need it below, obtain an estimate
1179 * of the selectivity of "x = constval". We use a calculation
1180 * similar to what var_eq_const() does for a non-MCV constant,
1181 * ie, estimate that all distinct non-MCV values occur equally
1182 * often. But multiplication by "1.0 - sumcommon - nullfrac"
1183 * will be done by our caller, so we shouldn't do that here.
1184 * Therefore we can't try to clamp the estimate by reference
1185 * to the least common MCV; the result would be too small.
1186 *
1187 * Note: since this is effectively assuming that constval
1188 * isn't an MCV, it's logically dubious if constval in fact is
1189 * one. But we have to apply *some* correction for equality,
1190 * and anyway we cannot tell if constval is an MCV, since we
1191 * don't have a suitable equality operator at hand.
1192 */
1194 {
1197 AttStatsSlot mcvslot;
1199 /* Get estimated number of distinct values */
1203 /* Subtract off the number of known MCVs */
1206 ATTSTATSSLOT_NUMBERS))
1207 {
1210 }
1212 /* If result doesn't seem sane, leave eq_selec at 0 */
1215 }
1217 /*
1218 * Convert the constant and the two nearest bin boundary
1219 * values to a uniform comparison scale, and do a linear
1220 * interpolation within this bin.
1221 */
1227 {
1229 {
1230 /* cope if bin boundaries appear identical */
1232 }
1237 else
1238 {
1241 /*
1242 * Watch out for the possibility that we got a NaN or
1243 * Infinity from the division. This can happen
1244 * despite the previous checks, if for example "low"
1245 * is -Infinity.
1246 */
1250 }
1251 }
1252 else
1253 {
1254 /*
1255 * Ideally we'd produce an error here, on the grounds that
1256 * the given operator shouldn't have scalarXXsel
1257 * registered as its selectivity func unless we can deal
1258 * with its operand types. But currently, all manner of
1259 * stuff is invoking scalarXXsel, so give a default
1260 * estimate until that can be fixed.
1261 */
1263 }
1265 /*
1266 * Now, compute the overall selectivity across the values
1267 * represented by the histogram. We have i-1 full bins and
1268 * binfrac partial bin below the constant.
1269 */
1273 /*
1274 * At this point, histfrac is an estimate of the fraction of
1275 * the population represented by the histogram that satisfies
1276 * "x <= constval". Somewhat remarkably, this statement is
1277 * true regardless of which operator we were doing the probes
1278 * with, so long as convert_to_scalar() delivers reasonable
1279 * results. If the probe constant is equal to some histogram
1280 * entry, we would have considered the bin to the left of that
1281 * entry if probing with "<" or ">=", or the bin to the right
1282 * if probing with "<=" or ">"; but binfrac would have come
1283 * out as 1.0 in the first case and 0.0 in the second, leading
1284 * to the same histfrac in either case. For probe constants
1285 * between histogram entries, we find the same bin and get the
1286 * same estimate with any operator.
1287 *
1288 * The fact that the estimate corresponds to "x <= constval"
1289 * and not "x < constval" is because of the way that ANALYZE
1290 * constructs the histogram: each entry is, effectively, the
1291 * rightmost value in its sample bucket. So selectivity
1292 * values that are exact multiples of 1/(histogram_size-1)
1293 * should be understood as estimates including a histogram
1294 * entry plus everything to its left.
1295 *
1296 * However, that breaks down for the first histogram entry,
1297 * which necessarily is the leftmost value in its sample
1298 * bucket. That means the first histogram bin is slightly
1299 * narrower than the rest, by an amount equal to eq_selec.
1300 * Another way to say that is that we want "x <= leftmost" to
1301 * be estimated as eq_selec not zero. So, if we're dealing
1302 * with the first bin (i==1), rescale to make that true while
1303 * adjusting the rest of that bin linearly.
1304 */
1308 /*
1309 * "x <= constval" is good if we want an estimate for "<=" or
1310 * ">", but if we are estimating for "<" or ">=", we now need
1311 * to decrease the estimate by eq_selec.
1312 */
1315 }
1317 /*
1318 * Now the estimate is finished for "<" and "<=" cases. If we are
1319 * estimating for ">" or ">=", flip it.
1320 */
1323 /*
1324 * The histogram boundaries are only approximate to begin with,
1325 * and may well be out of date anyway. Therefore, don't believe
1326 * extremely small or large selectivity estimates --- unless we
1327 * got actual current endpoint values from the table, in which
1328 * case just do the usual sanity clamp. Somewhat arbitrarily, we
1329 * set the cutoff for other cases at a hundredth of the histogram
1330 * resolution.
1331 */
1334 else
1335 {
1342 }
1343 }
1345 {
1346 /*
1347 * If we get here, we have a histogram but it's not sorted the way
1348 * we want. Do a brute-force search to see how many of the
1349 * entries satisfy the comparison condition, and take that
1350 * fraction as our estimate. (This is identical to the inner loop
1351 * of histogram_selectivity; maybe share code?)
1352 */
1362 {
1363 Datum fresult;
1369 nmatch++;
1370 }
1373 /*
1374 * As above, clamp to a hundredth of the histogram resolution.
1375 * This case is surely even less trustworthy than the normal one,
1376 * so we shouldn't believe exact 0 or 1 selectivity. (Maybe the
1377 * clamp should be more restrictive in this case?)
1378 */
1379 {
1386 }
1387 }
1390 }
1393 }
1395 /*
1396 * Common wrapper function for the selectivity estimators that simply
1397 * invoke scalarineqsel().
1398 */
1399 static Datum
1401 {
1407 VariableStatData vardata;
1410 Datum constval;
1411 Oid consttype;
1414 /*
1415 * If expression is not variable op something or something op variable,
1416 * then punt and return a default estimate.
1417 */
1422 /*
1423 * Can't do anything useful if the something is not a constant, either.
1424 */
1426 {
1429 }
1431 /*
1432 * If the constant is NULL, assume operator is strict and return zero, ie,
1433 * operator will never return TRUE.
1434 */
1436 {
1439 }
1443 /*
1444 * Force the var to be on the left to simplify logic in scalarineqsel.
1445 */
1447 {
1450 {
1451 /* Use default selectivity (should we raise an error instead?) */
1454 }
1456 }
1458 /* The rest of the work is done by scalarineqsel(). */
1465 }
1467 /*
1468 * scalarltsel - Selectivity of "<" for scalars.
1469 */
1470 Datum
1472 {
1474 }
1476 /*
1477 * scalarlesel - Selectivity of "<=" for scalars.
1478 */
1479 Datum
1481 {
1483 }
1485 /*
1486 * scalargtsel - Selectivity of ">" for scalars.
1487 */
1488 Datum
1490 {
1492 }
1494 /*
1495 * scalargesel - Selectivity of ">=" for scalars.
1496 */
1497 Datum
1499 {
1501 }
1503 /*
1504 * boolvarsel - Selectivity of Boolean variable.
1505 *
1506 * This can actually be called on any boolean-valued expression. If it
1507 * involves only Vars of the specified relation, and if there are statistics
1508 * about the Var or expression (the latter is possible if it's indexed) then
1509 * we'll produce a real estimate; otherwise it's just a default.
1510 */
1511 Selectivity
1513 {
1514 VariableStatData vardata;
1519 {
1520 /*
1521 * A boolean variable V is equivalent to the clause V = 't', so we
1522 * compute the selectivity as if that is what we have.
1523 */
1526 }
1527 else
1528 {
1529 /* Otherwise, the default estimate is 0.5 */
1531 }
1534 }
1536 /*
1537 * booltestsel - Selectivity of BooleanTest Node.
1538 */
1539 Selectivity
1542 {
1543 VariableStatData vardata;
1549 {
1550 Form_pg_statistic stats;
1552 AttStatsSlot sslot;
1561 {
1565 /*
1566 * Get first MCV frequency and derive frequency for true.
1567 */
1570 else
1573 /*
1574 * Next derive frequency for false. Then use these as appropriate
1575 * to derive frequency for each case.
1576 */
1580 {
1582 /* select only NULL values */
1586 /* select non-NULL values */
1590 /* select only TRUE values */
1594 /* select non-TRUE values */
1598 /* select only FALSE values */
1602 /* select non-FALSE values */
1610 }
1613 }
1614 else
1615 {
1616 /*
1617 * No most-common-value info available. Still have null fraction
1618 * information, so use it for IS [NOT] UNKNOWN. Otherwise adjust
1619 * for null fraction and assume a 50-50 split of TRUE and FALSE.
1620 */
1622 {
1624 /* select only NULL values */
1628 /* select non-NULL values */
1633 /* Assume we select half of the non-NULL values */
1638 /* Assume we select NULLs plus half of the non-NULLs */
1639 /* equiv. to freq_null + (1.0 - freq_null) / 2.0 */
1647 }
1648 }
1649 }
1650 else
1651 {
1652 /*
1653 * If we can't get variable statistics for the argument, perhaps
1654 * clause_selectivity can do something with it. We ignore the
1655 * possibility of a NULL value when using clause_selectivity, and just
1656 * assume the value is either TRUE or FALSE.
1657 */
1659 {
1669 varRelid,
1675 varRelid,
1683 }
1684 }
1688 /* result should be in range, but make sure... */
1692 }
1694 /*
1695 * nulltestsel - Selectivity of NullTest Node.
1696 */
1697 Selectivity
1700 {
1701 VariableStatData vardata;
1707 {
1708 Form_pg_statistic stats;
1715 {
1718 /*
1719 * Use freq_null directly.
1720 */
1725 /*
1726 * Select not unknown (not null) values. Calculate from
1727 * freq_null.
1728 */
1735 }
1736 }
1739 {
1740 /*
1741 * There are no stats for system columns, but we know they are never
1742 * NULL.
1743 */
1745 }
1746 else
1747 {
1748 /*
1749 * No ANALYZE stats available, so make a guess
1750 */
1752 {
1763 }
1764 }
1768 /* result should be in range, but make sure... */
1772 }
1774 /*
1775 * strip_array_coercion - strip binary-compatible relabeling from an array expr
1776 *
1777 * For array values, the parser normally generates ArrayCoerceExpr conversions,
1778 * but it seems possible that RelabelType might show up. Also, the planner
1779 * is not currently tense about collapsing stacked ArrayCoerceExpr nodes,
1780 * so we need to be ready to deal with more than one level.
1781 */
1784 {
1786 {
1788 {
1791 /*
1792 * If the per-element expression is just a RelabelType on top of
1793 * CaseTestExpr, then we know it's a binary-compatible relabeling.
1794 */
1798 else
1800 }
1802 {
1803 /* We don't really expect this case, but may as well cope */
1805 }
1806 else
1808 }
1810 }
1812 /*
1813 * scalararraysel - Selectivity of ScalarArrayOpExpr Node.
1814 */
1815 Selectivity
1820 JoinType jointype,
1822 {
1829 Oid nominal_element_type;
1830 Oid nominal_element_collation;
1832 RegProcedure oprsel;
1833 FmgrInfo oprselproc;
1834 Selectivity s1;
1835 Selectivity s1disjoint;
1837 /* First, deconstruct the expression */
1842 /* aggressively reduce both sides to constants */
1846 /* get nominal (after relabeling) element type of rightop */
1850 /* get nominal collation, too, for generating constants */
1853 /* look through any binary-compatible relabeling of rightop */
1856 /*
1857 * Detect whether the operator is the default equality or inequality
1858 * operator of the array element type.
1859 */
1862 {
1867 }
1869 /*
1870 * If it is equality or inequality, we might be able to estimate this as a
1871 * form of array containment; for instance "const = ANY(column)" can be
1872 * treated as "ARRAY[const] <@ column". scalararraysel_containment tries
1873 * that, and returns the selectivity estimate if successful, or -1 if not.
1874 */
1876 {
1878 nominal_element_type,
1882 }
1884 /*
1885 * Look up the underlying operator's selectivity estimator. Punt if it
1886 * hasn't got one.
1887 */
1890 else
1896 /*
1897 * In the array-containment check above, we must only believe that an
1898 * operator is equality or inequality if it is the default btree equality
1899 * operator (or its negator) for the element type, since those are the
1900 * operators that array containment will use. But in what follows, we can
1901 * be a little laxer, and also believe that any operators using eqsel() or
1902 * neqsel() as selectivity estimator act like equality or inequality.
1903 */
1909 /*
1910 * We consider three cases:
1911 *
1912 * 1. rightop is an Array constant: deconstruct the array, apply the
1913 * operator's selectivity function for each array element, and merge the
1914 * results in the same way that clausesel.c does for AND/OR combinations.
1915 *
1916 * 2. rightop is an ARRAY[] construct: apply the operator's selectivity
1917 * function for each element of the ARRAY[] construct, and merge.
1918 *
1919 * 3. otherwise, make a guess ...
1920 */
1922 {
1926 int16 elmlen;
1944 /*
1945 * For generic operators, we assume the probability of success is
1946 * independent for each array element. But for "= ANY" or "<> ALL",
1947 * if the array elements are distinct (which'd typically be the case)
1948 * then the probabilities are disjoint, and we should just sum them.
1949 *
1950 * If we were being really tense we would try to confirm that the
1951 * elements are all distinct, but that would be expensive and it
1952 * doesn't seem to be worth the cycles; it would amount to penalizing
1953 * well-written queries in favor of poorly-written ones. However, we
1954 * do protect ourselves a little bit by checking whether the
1955 * disjointness assumption leads to an impossible (out of range)
1956 * probability; if so, we fall back to the normal calculation.
1957 */
1961 {
1963 Selectivity s2;
1968 nominal_element_collation,
1969 elmlen,
1972 elmbyval));
1981 else
1990 {
1994 }
1995 else
1996 {
2000 }
2001 }
2003 /* accept disjoint-probability estimate if in range */
2007 }
2010 {
2012 int16 elmlen;
2019 /*
2020 * We use the assumption of disjoint probabilities here too, although
2021 * the odds of equal array elements are rather higher if the elements
2022 * are not all constants (which they won't be, else constant folding
2023 * would have reduced the ArrayExpr to a Const). In this path it's
2024 * critical to have the sanity check on the s1disjoint estimate.
2025 */
2029 {
2032 Selectivity s2;
2034 /*
2035 * Theoretically, if elem isn't of nominal_element_type we should
2036 * insert a RelabelType, but it seems unlikely that any operator
2037 * estimation function would really care ...
2038 */
2048 else
2057 {
2061 }
2062 else
2063 {
2067 }
2068 }
2070 /* accept disjoint-probability estimate if in range */
2074 }
2075 else
2076 {
2079 Selectivity s2;
2082 /*
2083 * We need a dummy rightop to pass to the operator selectivity
2084 * routine. It can be pretty much anything that doesn't look like a
2085 * constant; CaseTestExpr is a convenient choice.
2086 */
2100 else
2109 /*
2110 * Arbitrarily assume 10 elements in the eventual array value (see
2111 * also estimate_array_length). We don't risk an assumption of
2112 * disjoint probabilities here.
2113 */
2115 {
2118 else
2120 }
2121 }
2123 /* result should be in range, but make sure... */
2127 }
2129 /*
2130 * Estimate number of elements in the array yielded by an expression.
2131 *
2132 * Note: the result is integral, but we use "double" to avoid overflow
2133 * concerns. Most callers will use it in double-type expressions anyway.
2134 *
2135 * Note: in some code paths root can be passed as NULL, resulting in
2136 * slightly worse estimates.
2137 */
2138 double
2140 {
2141 /* look through any binary-compatible relabeling of arrayexpr */
2145 {
2154 }
2157 {
2159 }
2161 {
2162 /* See if we can find any statistics about it */
2163 VariableStatData vardata;
2164 AttStatsSlot sslot;
2169 {
2170 /*
2171 * Found stats, so use the average element count, which is stored
2172 * in the last stanumbers element of the DECHIST statistics.
2173 * Actually that is the average count of *distinct* elements;
2174 * perhaps we should scale it up somewhat?
2175 */
2178 ATTSTATSSLOT_NUMBERS))
2179 {
2183 }
2184 }
2189 }
2191 /* Else use a default guess --- this should match scalararraysel */
2193 }
2195 /*
2196 * rowcomparesel - Selectivity of RowCompareExpr Node.
2197 *
2198 * We estimate RowCompare selectivity by considering just the first (high
2199 * order) columns, which makes it equivalent to an ordinary OpExpr. While
2200 * this estimate could be refined by considering additional columns, it
2201 * seems unlikely that we could do a lot better without multi-column
2202 * statistics.
2203 */
2204 Selectivity
2208 {
2209 Selectivity s1;
2215 /* Build equivalent arg list for single operator */
2218 /*
2219 * Decide if it's a join clause. This should match clausesel.c's
2220 * treat_as_join_clause(), except that we intentionally consider only the
2221 * leading columns and not the rest of the clause.
2222 */
2224 {
2225 /*
2226 * Caller is forcing restriction mode (eg, because we are examining an
2227 * inner indexscan qual).
2228 */
2230 }
2232 {
2233 /*
2234 * It must be a restriction clause, since it's being evaluated at a
2235 * scan node.
2236 */
2238 }
2239 else
2240 {
2241 /*
2242 * Otherwise, it's a join if there's more than one base relation used.
2243 */
2245 }
2248 {
2249 /* Estimate selectivity for a join clause. */
2251 opargs,
2252 inputcollid,
2253 jointype,
2254 sjinfo);
2255 }
2256 else
2257 {
2258 /* Estimate selectivity for a restriction clause. */
2260 opargs,
2261 inputcollid,
2262 varRelid);
2263 }
2266 }
2268 /*
2269 * eqjoinsel - Join selectivity of "="
2270 */
2271 Datum
2273 {
2278 #ifdef NOT_USED
2280 #endif
2285 VariableStatData vardata1;
2286 VariableStatData vardata2;
2291 Oid opfuncoid;
2292 AttStatsSlot sslot1;
2293 AttStatsSlot sslot2;
2313 /*
2314 * There is no use in fetching one side's MCVs if we lack MCVs for the
2315 * other side, so do a quick check to verify that both stats exist.
2316 */
2327 {
2328 /* note we allow use of nullfrac regardless of security check */
2335 }
2338 {
2339 /* note we allow use of nullfrac regardless of security check */
2346 }
2348 /* We need to compute the inner-join selectivity in all cases */
2358 {
2367 /*
2368 * Look up the join's inner relation. min_righthand is sufficient
2369 * information because neither SEMI nor ANTI joins permit any
2370 * reassociation into or out of their RHS, so the righthand will
2371 * always be exactly that set of rels.
2372 */
2383 inner_rel);
2384 else
2385 {
2396 inner_rel);
2397 }
2399 /*
2400 * We should never estimate the output of a semijoin to be more
2401 * rows than we estimate for an inner join with the same input
2402 * rels and join condition; it's obviously impossible for that to
2403 * happen. The former estimate is N1 * Ssemi while the latter is
2404 * N1 * N2 * Sinner, so we may clamp Ssemi <= N2 * Sinner. Doing
2405 * this is worthwhile because of the shakier estimation rules we
2406 * use in eqjoinsel_semi, particularly in cases where it has to
2407 * punt entirely.
2408 */
2412 /* other values not expected here */
2417 }
2428 }
2430 /*
2431 * eqjoinsel_inner --- eqjoinsel for normal inner join
2432 *
2433 * We also use this for LEFT/FULL outer joins; it's not presently clear
2434 * that it's worth trying to distinguish them here.
2435 */
2436 static double
2444 {
2448 {
2449 /*
2450 * We have most-common-value lists for both relations. Run through
2451 * the lists to see which MCVs actually join to each other with the
2452 * given operator. This allows us to determine the exact join
2453 * selectivity for the portion of the relations represented by the MCV
2454 * lists. We still have to estimate for the remaining population, but
2455 * in a skewed distribution this gives us a big leg up in accuracy.
2456 * For motivation see the analysis in Y. Ioannidis and S.
2457 * Christodoulakis, "On the propagation of errors in the size of join
2458 * results", Technical Report 1018, Computer Science Dept., University
2459 * of Wisconsin, Madison, March 1991 (available from ftp.cs.wisc.edu).
2460 */
2462 FmgrInfo eqproc;
2468 matchfreq1,
2469 matchfreq2,
2470 unmatchfreq1,
2471 unmatchfreq2,
2472 otherfreq1,
2473 otherfreq2,
2474 totalsel1,
2475 totalsel2;
2477 nmatches;
2481 /*
2482 * Save a few cycles by setting up the fcinfo struct just once. Using
2483 * FunctionCallInvoke directly also avoids failure if the eqproc
2484 * returns NULL, though really equality functions should never do
2485 * that.
2486 */
2495 /*
2496 * Note we assume that each MCV will match at most one member of the
2497 * other MCV list. If the operator isn't really equality, there could
2498 * be multiple matches --- but we don't look for them, both for speed
2499 * and because the math wouldn't add up...
2500 */
2504 {
2510 {
2511 Datum fresult;
2519 {
2522 nmatches++;
2524 }
2525 }
2526 }
2528 /* Sum up frequencies of matched and unmatched MCVs */
2531 {
2534 else
2536 }
2541 {
2544 else
2546 }
2552 /*
2553 * Compute total frequency of non-null values that are not in the MCV
2554 * lists.
2555 */
2561 /*
2562 * We can estimate the total selectivity from the point of view of
2563 * relation 1 as: the known selectivity for matched MCVs, plus
2564 * unmatched MCVs that are assumed to match against random members of
2565 * relation 2's non-MCV population, plus non-MCV values that are
2566 * assumed to match against random members of relation 2's unmatched
2567 * MCVs plus non-MCV values.
2568 */
2575 /* Same estimate from the point of view of relation 2. */
2583 /*
2584 * Use the smaller of the two estimates. This can be justified in
2585 * essentially the same terms as given below for the no-stats case: to
2586 * a first approximation, we are estimating from the point of view of
2587 * the relation with smaller nd.
2588 */
2590 }
2591 else
2592 {
2593 /*
2594 * We do not have MCV lists for both sides. Estimate the join
2595 * selectivity as MIN(1/nd1,1/nd2)*(1-nullfrac1)*(1-nullfrac2). This
2596 * is plausible if we assume that the join operator is strict and the
2597 * non-null values are about equally distributed: a given non-null
2598 * tuple of rel1 will join to either zero or N2*(1-nullfrac2)/nd2 rows
2599 * of rel2, so total join rows are at most
2600 * N1*(1-nullfrac1)*N2*(1-nullfrac2)/nd2 giving a join selectivity of
2601 * not more than (1-nullfrac1)*(1-nullfrac2)/nd2. By the same logic it
2602 * is not more than (1-nullfrac1)*(1-nullfrac2)/nd1, so the expression
2603 * with MIN() is an upper bound. Using the MIN() means we estimate
2604 * from the point of view of the relation with smaller nd (since the
2605 * larger nd is determining the MIN). It is reasonable to assume that
2606 * most tuples in this rel will have join partners, so the bound is
2607 * probably reasonably tight and should be taken as-is.
2608 *
2609 * XXX Can we be smarter if we have an MCV list for just one side? It
2610 * seems that if we assume equal distribution for the other side, we
2611 * end up with the same answer anyway.
2612 */
2619 else
2621 }
2624 }
2626 /*
2627 * eqjoinsel_semi --- eqjoinsel for semi join
2628 *
2629 * (Also used for anti join, which we are supposed to estimate the same way.)
2630 * Caller has ensured that vardata1 is the LHS variable.
2631 * Unlike eqjoinsel_inner, we have to cope with opfuncoid being InvalidOid.
2632 */
2633 static double
2642 {
2645 /*
2646 * We clamp nd2 to be not more than what we estimate the inner relation's
2647 * size to be. This is intuitively somewhat reasonable since obviously
2648 * there can't be more than that many distinct values coming from the
2649 * inner rel. The reason for the asymmetry (ie, that we don't clamp nd1
2650 * likewise) is that this is the only pathway by which restriction clauses
2651 * applied to the inner rel will affect the join result size estimate,
2652 * since set_joinrel_size_estimates will multiply SEMI/ANTI selectivity by
2653 * only the outer rel's size. If we clamped nd1 we'd be double-counting
2654 * the selectivity of outer-rel restrictions.
2655 *
2656 * We can apply this clamping both with respect to the base relation from
2657 * which the join variable comes (if there is just one), and to the
2658 * immediate inner input relation of the current join.
2659 *
2660 * If we clamp, we can treat nd2 as being a non-default estimate; it's not
2661 * great, maybe, but it didn't come out of nowhere either. This is most
2662 * helpful when the inner relation is empty and consequently has no stats.
2663 */
2665 {
2667 {
2670 }
2671 }
2673 {
2676 }
2679 {
2680 /*
2681 * We have most-common-value lists for both relations. Run through
2682 * the lists to see which MCVs actually join to each other with the
2683 * given operator. This allows us to determine the exact join
2684 * selectivity for the portion of the relations represented by the MCV
2685 * lists. We still have to estimate for the remaining population, but
2686 * in a skewed distribution this gives us a big leg up in accuracy.
2687 */
2689 FmgrInfo eqproc;
2694 uncertainfrac,
2695 uncertain;
2697 nmatches,
2698 clamped_nvalues2;
2700 /*
2701 * The clamping above could have resulted in nd2 being less than
2702 * sslot2->nvalues; in which case, we assume that precisely the nd2
2703 * most common values in the relation will appear in the join input,
2704 * and so compare to only the first nd2 members of the MCV list. Of
2705 * course this is frequently wrong, but it's the best bet we can make.
2706 */
2711 /*
2712 * Save a few cycles by setting up the fcinfo struct just once. Using
2713 * FunctionCallInvoke directly also avoids failure if the eqproc
2714 * returns NULL, though really equality functions should never do
2715 * that.
2716 */
2725 /*
2726 * Note we assume that each MCV will match at most one member of the
2727 * other MCV list. If the operator isn't really equality, there could
2728 * be multiple matches --- but we don't look for them, both for speed
2729 * and because the math wouldn't add up...
2730 */
2733 {
2739 {
2740 Datum fresult;
2748 {
2750 nmatches++;
2752 }
2753 }
2754 }
2755 /* Sum up frequencies of matched MCVs */
2758 {
2761 }
2766 /*
2767 * Now we need to estimate the fraction of relation 1 that has at
2768 * least one join partner. We know for certain that the matched MCVs
2769 * do, so that gives us a lower bound, but we're really in the dark
2770 * about everything else. Our crude approach is: if nd1 <= nd2 then
2771 * assume all non-null rel1 rows have join partners, else assume for
2772 * the uncertain rows that a fraction nd2/nd1 have join partners. We
2773 * can discount the known-matched MCVs from the distinct-values counts
2774 * before doing the division.
2775 *
2776 * Crude as the above is, it's completely useless if we don't have
2777 * reliable ndistinct values for both sides. Hence, if either nd1 or
2778 * nd2 is default, punt and assume half of the uncertain rows have
2779 * join partners.
2780 */
2782 {
2787 else
2789 }
2790 else
2795 }
2796 else
2797 {
2798 /*
2799 * Without MCV lists for both sides, we can only use the heuristic
2800 * about nd1 vs nd2.
2801 */
2805 {
2808 else
2810 }
2811 else
2813 }
2816 }
2818 /*
2819 * neqjoinsel - Join selectivity of "!="
2820 */
2821 Datum
2823 {
2830 float8 result;
2833 {
2834 /*
2835 * For semi-joins, if there is more than one distinct value in the RHS
2836 * relation then every non-null LHS row must find a row to join since
2837 * it can only be equal to one of them. We'll assume that there is
2838 * always more than one distinct RHS value for the sake of stability,
2839 * though in theory we could have special cases for empty RHS
2840 * (selectivity = 0) and single-distinct-value RHS (selectivity =
2841 * fraction of LHS that has the same value as the single RHS value).
2842 *
2843 * For anti-joins, if we use the same assumption that there is more
2844 * than one distinct key in the RHS relation, then every non-null LHS
2845 * row must be suppressed by the anti-join.
2846 *
2847 * So either way, the selectivity estimate should be 1 - nullfrac.
2848 */
2849 VariableStatData leftvar;
2850 VariableStatData rightvar;
2852 HeapTuple statsTuple;
2859 else
2865 }
2866 else
2867 {
2868 /*
2869 * We want 1 - eqjoinsel() where the equality operator is the one
2870 * associated with this != operator, that is, its negator.
2871 */
2875 {
2876 result =
2878 collation,
2884 }
2885 else
2886 {
2887 /* Use default selectivity (should we raise an error instead?) */
2889 }
2891 }
2894 }
2896 /*
2897 * scalarltjoinsel - Join selectivity of "<" for scalars
2898 */
2899 Datum
2901 {
2903 }
2905 /*
2906 * scalarlejoinsel - Join selectivity of "<=" for scalars
2907 */
2908 Datum
2910 {
2912 }
2914 /*
2915 * scalargtjoinsel - Join selectivity of ">" for scalars
2916 */
2917 Datum
2919 {
2921 }
2923 /*
2924 * scalargejoinsel - Join selectivity of ">=" for scalars
2925 */
2926 Datum
2928 {
2930 }
2933 /*
2934 * mergejoinscansel - Scan selectivity of merge join.
2935 *
2936 * A merge join will stop as soon as it exhausts either input stream.
2937 * Therefore, if we can estimate the ranges of both input variables,
2938 * we can estimate how much of the input will actually be read. This
2939 * can have a considerable impact on the cost when using indexscans.
2940 *
2941 * Also, we can estimate how much of each input has to be read before the
2942 * first join pair is found, which will affect the join's startup time.
2943 *
2944 * clause should be a clause already known to be mergejoinable. opfamily,
2945 * strategy, and nulls_first specify the sort ordering being used.
2946 *
2947 * The outputs are:
2948 * *leftstart is set to the fraction of the left-hand variable expected
2949 * to be scanned before the first join pair is found (0 to 1).
2950 * *leftend is set to the fraction of the left-hand variable expected
2951 * to be scanned before the join terminates (0 to 1).
2952 * *rightstart, *rightend similarly for the right-hand variable.
2953 */
2954 void
2959 {
2962 VariableStatData leftvar,
2963 rightvar;
2965 Oid op_lefttype;
2966 Oid op_righttype;
2967 Oid opno,
2968 collation,
2969 lsortop,
2970 rsortop,
2971 lstatop,
2972 rstatop,
2973 ltop,
2974 leop,
2975 revltop,
2976 revleop;
2978 Datum leftmin,
2979 leftmax,
2980 rightmin,
2981 rightmax;
2984 /* Set default results if we can't figure anything out. */
2985 /* XXX should default "start" fraction be a bit more than 0? */
2989 /* Deconstruct the merge clause */
2999 /* Look for stats for the inputs */
3003 /* Extract the operator's declared left/right datatypes */
3010 /*
3011 * Look up the various operators we need. If we don't find them all, it
3012 * probably means the opfamily is broken, but we just fail silently.
3013 *
3014 * Note: we expect that pg_statistic histograms will be sorted by the '<'
3015 * operator, regardless of which sort direction we are considering.
3016 */
3018 {
3022 {
3023 /* easy case */
3026 BTLessStrategyNumber);
3029 BTLessEqualStrategyNumber);
3036 }
3037 else
3038 {
3041 BTLessStrategyNumber);
3044 BTLessEqualStrategyNumber);
3047 BTLessStrategyNumber);
3050 BTLessStrategyNumber);
3055 BTLessStrategyNumber);
3058 BTLessEqualStrategyNumber);
3059 }
3062 /* descending-order case */
3065 {
3066 /* easy case */
3069 BTGreaterStrategyNumber);
3072 BTGreaterEqualStrategyNumber);
3077 BTLessStrategyNumber);
3081 }
3082 else
3083 {
3086 BTGreaterStrategyNumber);
3089 BTGreaterEqualStrategyNumber);
3092 BTGreaterStrategyNumber);
3095 BTGreaterStrategyNumber);
3098 BTLessStrategyNumber);
3101 BTLessStrategyNumber);
3104 BTGreaterStrategyNumber);
3107 BTGreaterEqualStrategyNumber);
3108 }
3112 }
3124 /* Try to get ranges of both inputs */
3126 {
3133 }
3134 else
3135 {
3136 /* need to swap the max and min */
3143 }
3145 /*
3146 * Now, the fraction of the left variable that will be scanned is the
3147 * fraction that's <= the right-side maximum value. But only believe
3148 * non-default estimates, else stick with our 1.0.
3149 */
3155 /* And similarly for the right variable. */
3161 /*
3162 * Only one of the two "end" fractions can really be less than 1.0;
3163 * believe the smaller estimate and reset the other one to exactly 1.0. If
3164 * we get exactly equal estimates (as can easily happen with self-joins),
3165 * believe neither.
3166 */
3171 else
3174 /*
3175 * Also, the fraction of the left variable that will be scanned before the
3176 * first join pair is found is the fraction that's < the right-side
3177 * minimum value. But only believe non-default estimates, else stick with
3178 * our own default.
3179 */
3185 /* And similarly for the right variable. */
3191 /*
3192 * Only one of the two "start" fractions can really be more than zero;
3193 * believe the larger estimate and reset the other one to exactly 0.0. If
3194 * we get exactly equal estimates (as can easily happen with self-joins),
3195 * believe neither.
3196 */
3201 else
3204 /*
3205 * If the sort order is nulls-first, we're going to have to skip over any
3206 * nulls too. These would not have been counted by scalarineqsel, and we
3207 * can safely add in this fraction regardless of whether we believe
3208 * scalarineqsel's results or not. But be sure to clamp the sum to 1.0!
3209 */
3211 {
3212 Form_pg_statistic stats;
3215 {
3221 }
3223 {
3229 }
3230 }
3232 /* Disbelieve start >= end, just in case that can happen */
3234 {
3237 }
3239 {
3242 }
3244 fail:
3247 }
3250 /*
3251 * matchingsel -- generic matching-operator selectivity support
3252 *
3253 * Use these for any operators that (a) are on data types for which we collect
3254 * standard statistics, and (b) have behavior for which the default estimate
3255 * (twice DEFAULT_EQ_SEL) is sane. Typically that is good for match-like
3256 * operators.
3257 */
3259 Datum
3261 {
3269 /* Use generic restriction selectivity logic. */
3272 DEFAULT_MATCHING_SEL);
3275 }
3277 Datum
3279 {
3280 /* Just punt, for the moment. */
3282 }
3285 /*
3286 * Helper routine for estimate_num_groups: add an item to a list of
3287 * GroupVarInfos, but only if it's not known equal to any of the existing
3288 * entries.
3289 */
3291 {
3301 {
3310 {
3313 /* Drop exact duplicates */
3317 /*
3318 * Drop known-equal vars, but only if they belong to different
3319 * relations (see comments for estimate_num_groups). We aren't too
3320 * fussy about the semantics of "equal" here.
3321 */
3324 {
3326 {
3327 /* Keep older item, forget new one */
3329 }
3330 else
3331 {
3332 /* Delete the older item */
3334 }
3335 }
3336 }
3346 }
3348 /*
3349 * estimate_num_groups - Estimate number of groups in a grouped query
3350 *
3351 * Given a query having a GROUP BY clause, estimate how many groups there
3352 * will be --- ie, the number of distinct combinations of the GROUP BY
3353 * expressions.
3354 *
3355 * This routine is also used to estimate the number of rows emitted by
3356 * a DISTINCT filtering step; that is an isomorphic problem. (Note:
3357 * actually, we only use it for DISTINCT when there's no grouping or
3358 * aggregation ahead of the DISTINCT.)
3359 *
3360 * Inputs:
3361 * root - the query
3362 * groupExprs - list of expressions being grouped by
3363 * input_rows - number of rows estimated to arrive at the group/unique
3364 * filter step
3365 * pgset - NULL, or a List** pointing to a grouping set to filter the
3366 * groupExprs against
3367 *
3368 * Outputs:
3369 * estinfo - When passed as non-NULL, the function will set bits in the
3370 * "flags" field in order to provide callers with additional information
3371 * about the estimation. Currently, we only set the SELFLAG_USED_DEFAULT
3372 * bit if we used any default values in the estimation.
3373 *
3374 * Given the lack of any cross-correlation statistics in the system, it's
3375 * impossible to do anything really trustworthy with GROUP BY conditions
3376 * involving multiple Vars. We should however avoid assuming the worst
3377 * case (all possible cross-product terms actually appear as groups) since
3378 * very often the grouped-by Vars are highly correlated. Our current approach
3379 * is as follows:
3380 * 1. Expressions yielding boolean are assumed to contribute two groups,
3381 * independently of their content, and are ignored in the subsequent
3382 * steps. This is mainly because tests like "col IS NULL" break the
3383 * heuristic used in step 2 especially badly.
3384 * 2. Reduce the given expressions to a list of unique Vars used. For
3385 * example, GROUP BY a, a + b is treated the same as GROUP BY a, b.
3386 * It is clearly correct not to count the same Var more than once.
3387 * It is also reasonable to treat f(x) the same as x: f() cannot
3388 * increase the number of distinct values (unless it is volatile,
3389 * which we consider unlikely for grouping), but it probably won't
3390 * reduce the number of distinct values much either.
3391 * As a special case, if a GROUP BY expression can be matched to an
3392 * expressional index for which we have statistics, then we treat the
3393 * whole expression as though it were just a Var.
3394 * 3. If the list contains Vars of different relations that are known equal
3395 * due to equivalence classes, then drop all but one of the Vars from each
3396 * known-equal set, keeping the one with smallest estimated # of values
3397 * (since the extra values of the others can't appear in joined rows).
3398 * Note the reason we only consider Vars of different relations is that
3399 * if we considered ones of the same rel, we'd be double-counting the
3400 * restriction selectivity of the equality in the next step.
3401 * 4. For Vars within a single source rel, we multiply together the numbers
3402 * of values, clamp to the number of rows in the rel (divided by 10 if
3403 * more than one Var), and then multiply by a factor based on the
3404 * selectivity of the restriction clauses for that rel. When there's
3405 * more than one Var, the initial product is probably too high (it's the
3406 * worst case) but clamping to a fraction of the rel's rows seems to be a
3407 * helpful heuristic for not letting the estimate get out of hand. (The
3408 * factor of 10 is derived from pre-Postgres-7.4 practice.) The factor
3409 * we multiply by to adjust for the restriction selectivity assumes that
3410 * the restriction clauses are independent of the grouping, which may not
3411 * be a valid assumption, but it's hard to do better.
3412 * 5. If there are Vars from multiple rels, we repeat step 4 for each such
3413 * rel, and multiply the results together.
3414 * Note that rels not containing grouped Vars are ignored completely, as are
3415 * join clauses. Such rels cannot increase the number of groups, and we
3416 * assume such clauses do not reduce the number either (somewhat bogus,
3417 * but we don't have the info to do better).
3418 */
3419 double
3422 {
3429 /* Zero the estinfo output parameter, if non-NULL */
3433 /*
3434 * We don't ever want to return an estimate of zero groups, as that tends
3435 * to lead to division-by-zero and other unpleasantness. The input_rows
3436 * estimate is usually already at least 1, but clamp it just in case it
3437 * isn't.
3438 */
3441 /*
3442 * If no grouping columns, there's exactly one group. (This can't happen
3443 * for normal cases with GROUP BY or DISTINCT, but it is possible for
3444 * corner cases with set operations.)
3445 */
3449 /*
3450 * Count groups derived from boolean grouping expressions. For other
3451 * expressions, find the unique Vars used, treating an expression as a Var
3452 * if we can find stats for it. For each one, record the statistical
3453 * estimate of number of distinct values (total in its table, without
3454 * regard for filtering).
3455 */
3460 {
3463 VariableStatData vardata;
3467 /* is expression in this grouping set? */
3471 /*
3472 * Set-returning functions in grouping columns are a bit problematic.
3473 * The code below will effectively ignore their SRF nature and come up
3474 * with a numdistinct estimate as though they were scalar functions.
3475 * We compensate by scaling up the end result by the largest SRF
3476 * rowcount estimate. (This will be an overestimate if the SRF
3477 * produces multiple copies of any output value, but it seems best to
3478 * assume the SRF's outputs are distinct. In any case, it's probably
3479 * pointless to worry too much about this without much better
3480 * estimates for SRF output rowcounts than we have today.)
3481 */
3486 /* Short-circuit for expressions returning boolean */
3488 {
3491 }
3493 /*
3494 * If examine_variable is able to deduce anything about the GROUP BY
3495 * expression, treat it as a single variable even if it's really more
3496 * complicated.
3497 *
3498 * XXX This has the consequence that if there's a statistics object on
3499 * the expression, we don't split it into individual Vars. This
3500 * affects our selection of statistics in
3501 * estimate_multivariate_ndistinct, because it's probably better to
3502 * use more accurate estimate for each expression and treat them as
3503 * independent, than to combine estimates for the extracted variables
3504 * when we don't know how that relates to the expressions.
3505 */
3508 {
3513 }
3516 /*
3517 * Else pull out the component Vars. Handle PlaceHolderVars by
3518 * recursing into their arguments (effectively assuming that the
3519 * PlaceHolderVar doesn't change the number of groups, which boils
3520 * down to ignoring the possible addition of nulls to the result set).
3521 */
3523 PVC_RECURSE_AGGREGATES |
3524 PVC_RECURSE_WINDOWFUNCS |
3525 PVC_RECURSE_PLACEHOLDERS);
3527 /*
3528 * If we find any variable-free GROUP BY item, then either it is a
3529 * constant (and we can ignore it) or it contains a volatile function;
3530 * in the latter case we punt and assume that each input row will
3531 * yield a distinct group.
3532 */
3534 {
3538 }
3540 /*
3541 * Else add variables to varinfos list
3542 */
3544 {
3550 }
3551 }
3553 /*
3554 * If now no Vars, we must have an all-constant or all-boolean GROUP BY
3555 * list.
3556 */
3558 {
3559 /* Apply SRF multiplier as we would do in the long path */
3561 /* Round off */
3563 /* Guard against out-of-range answers */
3569 }
3571 /*
3572 * Group Vars by relation and estimate total numdistinct.
3573 *
3574 * For each iteration of the outer loop, we process the frontmost Var in
3575 * varinfos, plus all other Vars in the same relation. We remove these
3576 * Vars from the newvarinfos list for the next iteration. This is the
3577 * easiest way to group Vars of same rel together.
3578 */
3579 do
3580 {
3589 /*
3590 * Split the list of varinfos in two - one for the current rel, one
3591 * for remaining Vars on other rels.
3592 */
3595 {
3599 {
3600 /* varinfos on current rel */
3602 }
3603 else
3604 {
3605 /* not time to process varinfo2 yet */
3607 }
3608 }
3610 /*
3611 * Get the numdistinct estimate for the Vars of this rel. We
3612 * iteratively search for multivariate n-distinct with maximum number
3613 * of vars; assuming that each var group is independent of the others,
3614 * we multiply them together. Any remaining relvarinfos after no more
3615 * multivariate matches are found are assumed independent too, so
3616 * their individual ndistinct estimates are multiplied also.
3617 *
3618 * While iterating, count how many separate numdistinct values we
3619 * apply. We apply a fudge factor below, but only if we multiplied
3620 * more than one such values.
3621 */
3623 {
3628 {
3632 relvarcount++;
3633 }
3634 else
3635 {
3637 {
3643 relvarcount++;
3645 /*
3646 * When varinfo2's isdefault is set then we'd better set
3647 * the SELFLAG_USED_DEFAULT bit in the EstimationInfo.
3648 */
3651 }
3653 /* we're done with this relation */
3655 }
3656 }
3658 /*
3659 * Sanity check --- don't divide by zero if empty relation.
3660 */
3663 {
3664 /*
3665 * Clamp to size of rel, or size of rel / 10 if multiple Vars. The
3666 * fudge factor is because the Vars are probably correlated but we
3667 * don't know by how much. We should never clamp to less than the
3668 * largest ndistinct value for any of the Vars, though, since
3669 * there will surely be at least that many groups.
3670 */
3674 {
3677 {
3679 /* for sanity in case some ndistinct is too large: */
3682 }
3683 }
3687 /*
3688 * Update the estimate based on the restriction selectivity,
3689 * guarding against division by zero when reldistinct is zero.
3690 * Also skip this if we know that we are returning all rows.
3691 */
3693 {
3694 /*
3695 * Given a table containing N rows with n distinct values in a
3696 * uniform distribution, if we select p rows at random then
3697 * the expected number of distinct values selected is
3698 *
3699 * n * (1 - product((N-N/n-i)/(N-i), i=0..p-1))
3700 *
3701 * = n * (1 - (N-N/n)! / (N-N/n-p)! * (N-p)! / N!)
3702 *
3703 * See "Approximating block accesses in database
3704 * organizations", S. B. Yao, Communications of the ACM,
3705 * Volume 20 Issue 4, April 1977 Pages 260-261.
3706 *
3707 * Alternatively, re-arranging the terms from the factorials,
3708 * this may be written as
3709 *
3710 * n * (1 - product((N-p-i)/(N-i), i=0..N/n-1))
3711 *
3712 * This form of the formula is more efficient to compute in
3713 * the common case where p is larger than N/n. Additionally,
3714 * as pointed out by Dell'Era, if i << N for all terms in the
3715 * product, it can be approximated by
3716 *
3717 * n * (1 - ((N-p)/N)^(N/n))
3718 *
3719 * See "Expected distinct values when selecting from a bag
3720 * without replacement", Alberto Dell'Era,
3721 * http://www.adellera.it/investigations/distinct_balls/.
3722 *
3723 * The condition i << N is equivalent to n >> 1, so this is a
3724 * good approximation when the number of distinct values in
3725 * the table is large. It turns out that this formula also
3726 * works well even when n is small.
3727 */
3728 reldistinct *=
3731 }
3734 /*
3735 * Update estimate of total distinct groups.
3736 */
3738 }
3743 /* Now we can account for the effects of any SRFs */
3746 /* Round off */
3749 /* Guard against out-of-range answers */
3756 }
3758 /*
3759 * Estimate hash bucket statistics when the specified expression is used
3760 * as a hash key for the given number of buckets.
3761 *
3762 * This attempts to determine two values:
3763 *
3764 * 1. The frequency of the most common value of the expression (returns
3765 * zero into *mcv_freq if we can't get that).
3766 *
3767 * 2. The "bucketsize fraction", ie, average number of entries in a bucket
3768 * divided by total tuples in relation.
3769 *
3770 * XXX This is really pretty bogus since we're effectively assuming that the
3771 * distribution of hash keys will be the same after applying restriction
3772 * clauses as it was in the underlying relation. However, we are not nearly
3773 * smart enough to figure out how the restrict clauses might change the
3774 * distribution, so this will have to do for now.
3775 *
3776 * We are passed the number of buckets the executor will use for the given
3777 * input relation. If the data were perfectly distributed, with the same
3778 * number of tuples going into each available bucket, then the bucketsize
3779 * fraction would be 1/nbuckets. But this happy state of affairs will occur
3780 * only if (a) there are at least nbuckets distinct data values, and (b)
3781 * we have a not-too-skewed data distribution. Otherwise the buckets will
3782 * be nonuniformly occupied. If the other relation in the join has a key
3783 * distribution similar to this one's, then the most-loaded buckets are
3784 * exactly those that will be probed most often. Therefore, the "average"
3785 * bucket size for costing purposes should really be taken as something close
3786 * to the "worst case" bucket size. We try to estimate this by adjusting the
3787 * fraction if there are too few distinct data values, and then scaling up
3788 * by the ratio of the most common value's frequency to the average frequency.
3789 *
3790 * If no statistics are available, use a default estimate of 0.1. This will
3791 * discourage use of a hash rather strongly if the inner relation is large,
3792 * which is what we want. We do not want to hash unless we know that the
3793 * inner rel is well-dispersed (or the alternatives seem much worse).
3794 *
3795 * The caller should also check that the mcv_freq is not so large that the
3796 * most common value would by itself require an impractically large bucket.
3797 * In a hash join, the executor can split buckets if they get too big, but
3798 * obviously that doesn't help for a bucket that contains many duplicates of
3799 * the same value.
3800 */
3801 void
3805 {
3806 VariableStatData vardata;
3808 ndistinct,
3809 stanullfrac,
3810 avgfreq;
3812 AttStatsSlot sslot;
3816 /* Look up the frequency of the most common value, if available */
3820 {
3823 ATTSTATSSLOT_NUMBERS))
3824 {
3825 /*
3826 * The first MCV stat is for the most common value.
3827 */
3831 }
3832 }
3834 /* Get number of distinct values */
3837 /*
3838 * If ndistinct isn't real, punt. We normally return 0.1, but if the
3839 * mcv_freq is known to be even higher than that, use it instead.
3840 */
3842 {
3846 }
3848 /* Get fraction that are null */
3850 {
3851 Form_pg_statistic stats;
3855 }
3856 else
3859 /* Compute avg freq of all distinct data values in raw relation */
3862 /*
3863 * Adjust ndistinct to account for restriction clauses. Observe we are
3864 * assuming that the data distribution is affected uniformly by the
3865 * restriction clauses!
3866 *
3867 * XXX Possibly better way, but much more expensive: multiply by
3868 * selectivity of rel's restriction clauses that mention the target Var.
3869 */
3871 {
3874 }
3876 /*
3877 * Initial estimate of bucketsize fraction is 1/nbuckets as long as the
3878 * number of buckets is less than the expected number of distinct values;
3879 * otherwise it is 1/ndistinct.
3880 */
3883 else
3886 /*
3887 * Adjust estimated bucketsize upward to account for skewed distribution.
3888 */
3892 /*
3893 * Clamp bucketsize to sane range (the above adjustment could easily
3894 * produce an out-of-range result). We set the lower bound a little above
3895 * zero, since zero isn't a very sane result.
3896 */
3905 }
3907 /*
3908 * estimate_hashagg_tablesize
3909 * estimate the number of bytes that a hash aggregate hashtable will
3910 * require based on the agg_costs, path width and number of groups.
3911 *
3912 * We return the result as "double" to forestall any possible overflow
3913 * problem in the multiplication by dNumGroups.
3914 *
3915 * XXX this may be over-estimating the size now that hashagg knows to omit
3916 * unneeded columns from the hashtable. Also for mixed-mode grouping sets,
3917 * grouping columns not in the hashed set are counted here even though hashagg
3918 * won't store them. Is this a problem?
3919 */
3920 double
3923 {
3924 Size hashentrysize;
3930 /*
3931 * Note that this disregards the effect of fill-factor and growth policy
3932 * of the hash table. That's probably ok, given that the default
3933 * fill-factor is relatively high. It'd be hard to meaningfully factor in
3934 * "double-in-size" growth policies here.
3935 */
3937 }
3940 /*-------------------------------------------------------------------------
3941 *
3942 * Support routines
3943 *
3944 *-------------------------------------------------------------------------
3945 */
3947 /*
3948 * Find applicable ndistinct statistics for the given list of VarInfos (which
3949 * must all belong to the given rel), and update *ndistinct to the estimate of
3950 * the MVNDistinctItem that best matches. If a match it found, *varinfos is
3951 * updated to remove the list of matched varinfos.
3952 *
3953 * Varinfos that aren't for simple Vars are ignored.
3954 *
3955 * Return true if we're able to find a match, false otherwise.
3956 */
3957 static bool
3960 {
3969 /* bail out immediately if the table has no extended statistics */
3973 /* look for the ndistinct statistics object matching the most vars */
3977 {
3983 /* skip statistics of other kinds */
3987 /* skip statistics with mismatching stxdinherit value */
3991 /*
3992 * Determine how many expressions (and variables in non-matched
3993 * expressions) match. We'll then use these numbers to pick the
3994 * statistics object that best matches the clauses.
3995 */
3997 {
4000 AttrNumber attnum;
4004 /* simple Var, search in statistics keys directly */
4006 {
4009 /*
4010 * Ignore system attributes - we don't support statistics on
4011 * them, so can't match them (and it'd fail as the values are
4012 * negative).
4013 */
4018 nshared_vars++;
4021 }
4023 /* expression - see if it's in the statistics object */
4025 {
4029 {
4030 nshared_exprs++;
4032 }
4033 }
4034 }
4039 /*
4040 * Does this statistics object match more columns than the currently
4041 * best object? If so, use this one instead.
4042 *
4043 * XXX This should break ties using name of the object, or something
4044 * like that, to make the outcome stable.
4045 */
4048 {
4053 }
4054 }
4056 /* No match? */
4064 /*
4065 * If we have a match, search it for the specific item that matches (there
4066 * must be one), and construct the output values.
4067 */
4069 {
4075 AttrNumber attnum_offset;
4077 /*
4078 * How much we need to offset the attnums? If there are no
4079 * expressions, no offset is needed. Otherwise offset enough to move
4080 * the lowest one (which is equal to number of expressions) to 1.
4081 */
4084 else
4087 /* see what actually matched */
4089 {
4096 /*
4097 * Process a simple Var expression, by matching it to keys
4098 * directly. If there's a matching expression, we'll try matching
4099 * it later.
4100 */
4102 {
4105 /*
4106 * Ignore expressions on system attributes. Can't rely on the
4107 * bms check for negative values.
4108 */
4112 /* Is the variable covered by the statistics object? */
4118 /* ensure sufficient offset */
4124 }
4126 /*
4127 * XXX Maybe we should allow searching the expressions even if we
4128 * found an attribute matching the expression? That would handle
4129 * trivial expressions like "(a)" but it seems fairly useless.
4130 */
4134 /* expression - see if it's in the statistics object */
4137 {
4141 {
4146 /* ensure sufficient offset */
4151 /* there should be just one matching expression */
4153 }
4155 idx++;
4156 }
4157 }
4159 /* Find the specific item that exactly matches the combination */
4161 {
4168 /* assume it's the right item */
4171 /* check that all item attributes/expressions fit the match */
4173 {
4176 /*
4177 * Thanks to how we constructed the matched bitmap above, we
4178 * can just offset all attnums the same way.
4179 */
4183 {
4184 /* nah, it's not this item */
4187 }
4188 }
4190 /*
4191 * If the item has all the matched attributes, we know it's the
4192 * right one - there can't be a better one. matching more.
4193 */
4196 }
4198 /*
4199 * Make sure we found an item. There has to be one, because ndistinct
4200 * statistics includes all combinations of attributes.
4201 */
4205 /* Form the output varinfo list, keeping only unmatched ones */
4207 {
4212 /*
4213 * Let's look at plain variables first, because it's the most
4214 * common case and the check is quite cheap. We can simply get the
4215 * attnum and check (with an offset) matched bitmap.
4216 */
4218 {
4221 /*
4222 * If it's a system attribute, we're done. We don't support
4223 * extended statistics on system attributes, so it's clearly
4224 * not matched. Just keep the expression and continue.
4225 */
4227 {
4230 }
4232 /* apply the same offset as above */
4235 /* if it's not matched, keep the varinfo */
4239 /* The rest of the loop deals with complex expressions. */
4241 }
4243 /*
4244 * Process complex expressions, not just simple Vars.
4245 *
4246 * First, we search for an exact match of an expression. If we
4247 * find one, we can just discard the whole GroupVarInfo, with all
4248 * the variables we extracted from it.
4249 *
4250 * Otherwise we inspect the individual vars, and try matching it
4251 * to variables in the item.
4252 */
4254 {
4258 {
4261 }
4262 }
4264 /* found exact match, skip */
4269 }
4274 }
4277 }
4279 /*
4280 * convert_to_scalar
4281 * Convert non-NULL values of the indicated types to the comparison
4282 * scale needed by scalarineqsel().
4283 * Returns "true" if successful.
4284 *
4285 * XXX this routine is a hack: ideally we should look up the conversion
4286 * subroutines in pg_type.
4287 *
4288 * All numeric datatypes are simply converted to their equivalent
4289 * "double" values. (NUMERIC values that are outside the range of "double"
4290 * are clamped to +/- HUGE_VAL.)
4291 *
4292 * String datatypes are converted by convert_string_to_scalar(),
4293 * which is explained below. The reason why this routine deals with
4294 * three values at a time, not just one, is that we need it for strings.
4295 *
4296 * The bytea datatype is just enough different from strings that it has
4297 * to be treated separately.
4298 *
4299 * The several datatypes representing absolute times are all converted
4300 * to Timestamp, which is actually an int64, and then we promote that to
4301 * a double. Note this will give correct results even for the "special"
4302 * values of Timestamp, since those are chosen to compare correctly;
4303 * see timestamp_cmp.
4304 *
4305 * The several datatypes representing relative times (intervals) are all
4306 * converted to measurements expressed in seconds.
4307 */
4308 static bool
4312 {
4315 /*
4316 * Both the valuetypid and the boundstypid should exactly match the
4317 * declared input type(s) of the operator we are invoked for. However,
4318 * extensions might try to use scalarineqsel as estimator for operators
4319 * with input type(s) we don't handle here; in such cases, we want to
4320 * return false, not fail. In any case, we mustn't assume that valuetypid
4321 * and boundstypid are identical.
4322 *
4323 * XXX The histogram we are interpolating between points of could belong
4324 * to a column that's only binary-compatible with the declared type. In
4325 * essence we are assuming that the semantics of binary-compatible types
4326 * are enough alike that we can use a histogram generated with one type's
4327 * operators to estimate selectivity for the other's. This is outright
4328 * wrong in some cases --- in particular signed versus unsigned
4329 * interpretation could trip us up. But it's useful enough in the
4330 * majority of cases that we do it anyway. Should think about more
4331 * rigorous ways to do it.
4332 */
4334 {
4335 /*
4336 * Built-in numeric types
4337 */
4365 /*
4366 * Built-in string types
4367 */
4373 {
4381 /*
4382 * Bail out if any of the values is not of string type. We
4383 * might leak converted strings for the other value(s), but
4384 * that's not worth troubling over.
4385 */
4396 }
4398 /*
4399 * Built-in bytea type
4400 */
4402 {
4403 /* We only support bytea vs bytea comparison */
4410 }
4412 /*
4413 * Built-in time types
4414 */
4429 /*
4430 * Built-in network types
4431 */
4443 }
4444 /* Don't know how to convert */
4447 }
4449 /*
4450 * Do convert_to_scalar()'s work for any numeric data type.
4451 *
4452 * On failure (e.g., unsupported typid), set *failure to true;
4453 * otherwise, that variable is not changed.
4454 */
4455 static double
4457 {
4459 {
4473 /* Note: out-of-range values will be clamped to +-HUGE_VAL */
4476 value));
4489 /* we can treat OIDs as integers... */
4491 }
4495 }
4497 /*
4498 * Do convert_to_scalar()'s work for any character-string data type.
4499 *
4500 * String datatypes are converted to a scale that ranges from 0 to 1,
4501 * where we visualize the bytes of the string as fractional digits.
4502 *
4503 * We do not want the base to be 256, however, since that tends to
4504 * generate inflated selectivity estimates; few databases will have
4505 * occurrences of all 256 possible byte values at each position.
4506 * Instead, use the smallest and largest byte values seen in the bounds
4507 * as the estimated range for each byte, after some fudging to deal with
4508 * the fact that we probably aren't going to see the full range that way.
4509 *
4510 * An additional refinement is that we discard any common prefix of the
4511 * three strings before computing the scaled values. This allows us to
4512 * "zoom in" when we encounter a narrow data range. An example is a phone
4513 * number database where all the values begin with the same area code.
4514 * (Actually, the bounds will be adjacent histogram-bin-boundary values,
4515 * so this is more likely to happen than you might think.)
4516 */
4517 static void
4524 {
4526 rangehi;
4531 {
4536 }
4538 {
4543 }
4544 /* If range includes any upper-case ASCII chars, make it include all */
4546 {
4551 }
4552 /* Ditto lower-case */
4554 {
4559 }
4560 /* Ditto digits */
4562 {
4567 }
4569 /*
4570 * If range includes less than 10 chars, assume we have not got enough
4571 * data, and make it include regular ASCII set.
4572 */
4574 {
4577 }
4579 /*
4580 * Now strip any common prefix of the three strings.
4581 */
4583 {
4587 }
4589 /*
4590 * Now we can do the conversions.
4591 */
4595 }
4597 static double
4599 {
4602 denom,
4603 base;
4608 /*
4609 * There seems little point in considering more than a dozen bytes from
4610 * the string. Since base is at least 10, that will give us nominal
4611 * resolution of at least 12 decimal digits, which is surely far more
4612 * precision than this estimation technique has got anyway (especially in
4613 * non-C locales). Also, even with the maximum possible base of 256, this
4614 * ensures denom cannot grow larger than 256^13 = 2.03e31, which will not
4615 * overflow on any known machine.
4616 */
4620 /* Convert initial characters to fraction */
4625 {
4634 }
4637 }
4639 /*
4640 * Convert a string-type Datum into a palloc'd, null-terminated string.
4641 *
4642 * On failure (e.g., unsupported typid), set *failure to true;
4643 * otherwise, that variable is not changed. (We'll return NULL on failure.)
4644 *
4645 * When using a non-C locale, we must pass the string through pg_strxfrm()
4646 * before continuing, so as to generate correct locale-specific results.
4647 */
4650 {
4652 pg_locale_t mylocale;
4655 {
4667 {
4672 }
4676 }
4681 {
4686 /*
4687 * XXX: We could guess at a suitable output buffer size and only call
4688 * pg_strxfrm() twice if our guess is too small.
4689 *
4690 * XXX: strxfrm doesn't support UTF-8 encoding on Win32, it can return
4691 * bogus data or set an error. This is not really a problem unless it
4692 * crashes since it will only give an estimation error and nothing
4693 * fatal.
4694 *
4695 * XXX: we do not check pg_strxfrm_enabled(). On some platforms and in
4696 * some cases, libc strxfrm() may return the wrong results, but that
4697 * will only lead to an estimation error.
4698 */
4700 #ifdef WIN32
4702 /*
4703 * On Windows, strxfrm returns INT_MAX when an error occurs. Instead
4704 * of trying to allocate this much memory (and fail), just return the
4705 * original string unmodified as if we were in the C locale.
4706 */
4709 #endif
4713 /*
4714 * Some systems (e.g., glibc) can return a smaller value from the
4715 * second call than the first; thus the Assert must be <= not ==.
4716 */
4720 }
4723 }
4725 /*
4726 * Do convert_to_scalar()'s work for any bytea data type.
4727 *
4728 * Very similar to convert_string_to_scalar except we can't assume
4729 * null-termination and therefore pass explicit lengths around.
4730 *
4731 * Also, assumptions about likely "normal" ranges of characters have been
4732 * removed - a data range of 0..255 is always used, for now. (Perhaps
4733 * someday we will add information about actual byte data range to
4734 * pg_statistic.)
4735 */
4736 static void
4739 Datum lobound,
4741 Datum hibound,
4743 {
4748 rangehi,
4752 i,
4753 minlen;
4758 /*
4759 * Assume bytea data is uniformly distributed across all byte values.
4760 */
4764 /*
4765 * Now strip any common prefix of the three strings.
4766 */
4769 {
4774 }
4776 /*
4777 * Now we can do the conversions.
4778 */
4782 }
4784 static double
4787 {
4789 denom,
4790 base;
4795 /*
4796 * Since base is 256, need not consider more than about 10 chars (even
4797 * this many seems like overkill)
4798 */
4802 /* Convert initial characters to fraction */
4807 {
4816 }
4819 }
4821 /*
4822 * Do convert_to_scalar()'s work for any timevalue data type.
4823 *
4824 * On failure (e.g., unsupported typid), set *failure to true;
4825 * otherwise, that variable is not changed.
4826 */
4827 static double
4829 {
4831 {
4839 {
4842 /*
4843 * Convert the month part of Interval to days using assumed
4844 * average month length of 365.25/12.0 days. Not too
4845 * accurate, but plenty good enough for our purposes.
4846 *
4847 * This also works for infinite intervals, which just have all
4848 * fields set to INT_MIN/INT_MAX, and so will produce a result
4849 * smaller/larger than any finite interval.
4850 */
4853 }
4857 {
4860 /* use GMT-equivalent time */
4862 }
4863 }
4867 }
4870 /*
4871 * get_restriction_variable
4872 * Examine the args of a restriction clause to see if it's of the
4873 * form (variable op pseudoconstant) or (pseudoconstant op variable),
4874 * where "variable" could be either a Var or an expression in vars of a
4875 * single relation. If so, extract information about the variable,
4876 * and also indicate which side it was on and the other argument.
4877 *
4878 * Inputs:
4879 * root: the planner info
4880 * args: clause argument list
4881 * varRelid: see specs for restriction selectivity functions
4882 *
4883 * Outputs: (these are valid only if true is returned)
4884 * *vardata: gets information about variable (see examine_variable)
4885 * *other: gets other clause argument, aggressively reduced to a constant
4886 * *varonleft: set true if variable is on the left, false if on the right
4887 *
4888 * Returns true if a variable is identified, otherwise false.
4889 *
4890 * Note: if there are Vars on both sides of the clause, we must fail, because
4891 * callers are expecting that the other side will act like a pseudoconstant.
4892 */
4893 bool
4897 {
4900 VariableStatData rdata;
4902 /* Fail if not a binary opclause (probably shouldn't happen) */
4909 /*
4910 * Examine both sides. Note that when varRelid is nonzero, Vars of other
4911 * relations will be treated as pseudoconstants.
4912 */
4916 /*
4917 * If one side is a variable and the other not, we win.
4918 */
4920 {
4923 /* Assume we need no ReleaseVariableStats(rdata) here */
4925 }
4928 {
4931 /* Assume we need no ReleaseVariableStats(*vardata) here */
4934 }
4936 /* Oops, clause has wrong structure (probably var op var) */
4941 }
4943 /*
4944 * get_join_variables
4945 * Apply examine_variable() to each side of a join clause.
4946 * Also, attempt to identify whether the join clause has the same
4947 * or reversed sense compared to the SpecialJoinInfo.
4948 *
4949 * We consider the join clause "normal" if it is "lhs_var OP rhs_var",
4950 * or "reversed" if it is "rhs_var OP lhs_var". In complicated cases
4951 * where we can't tell for sure, we default to assuming it's normal.
4952 */
4953 void
4957 {
4976 else
4978 }
4980 /* statext_expressions_load copies the tuple, so just pfree it. */
4981 static void
4983 {
4985 }
4987 /*
4988 * examine_variable
4989 * Try to look up statistical data about an expression.
4990 * Fill in a VariableStatData struct to describe the expression.
4991 *
4992 * Inputs:
4993 * root: the planner info
4994 * node: the expression tree to examine
4995 * varRelid: see specs for restriction selectivity functions
4996 *
4997 * Outputs: *vardata is filled as follows:
4998 * var: the input expression (with any binary relabeling stripped, if
4999 * it is or contains a variable; but otherwise the type is preserved)
5000 * rel: RelOptInfo for relation containing variable; NULL if expression
5001 * contains no Vars (NOTE this could point to a RelOptInfo of a
5002 * subquery, not one in the current query).
5003 * statsTuple: the pg_statistic entry for the variable, if one exists;
5004 * otherwise NULL.
5005 * freefunc: pointer to a function to release statsTuple with.
5006 * vartype: exposed type of the expression; this should always match
5007 * the declared input type of the operator we are estimating for.
5008 * atttype, atttypmod: actual type/typmod of the "var" expression. This is
5009 * commonly the same as the exposed type of the variable argument,
5010 * but can be different in binary-compatible-type cases.
5011 * isunique: true if we were able to match the var to a unique index or a
5012 * single-column DISTINCT clause, implying its values are unique for
5013 * this query. (Caution: this should be trusted for statistical
5014 * purposes only, since we do not check indimmediate nor verify that
5015 * the exact same definition of equality applies.)
5016 * acl_ok: true if current user has permission to read the column(s)
5017 * underlying the pg_statistic entry. This is consulted by
5018 * statistic_proc_security_check().
5019 *
5020 * Caller is responsible for doing ReleaseVariableStats() before exiting.
5021 */
5022 void
5025 {
5027 Relids varnos;
5030 /* Make sure we don't return dangling pointers in vardata */
5033 /* Save the exposed type of the expression */
5036 /* Look inside any binary-compatible relabeling */
5040 else
5043 /* Fast path for a simple Var */
5047 {
5050 /* Set up result fields other than the stats tuple */
5057 /* Try to locate some stats */
5061 }
5063 /*
5064 * Okay, it's a more complicated expression. Determine variable
5065 * membership. Note that when varRelid isn't zero, only vars of that
5066 * relation are considered "real" vars.
5067 */
5073 {
5074 /* No Vars at all ... must be pseudo-constant clause */
5075 }
5076 else
5077 {
5081 {
5083 {
5087 }
5088 /* else treat it as a constant */
5089 }
5090 else
5091 {
5092 /* varnos has multiple relids */
5094 {
5095 /* treat it as a variable of a join relation */
5098 }
5100 {
5101 /* ignore the vars belonging to other relations */
5104 /* note: no point in expressional-index search here */
5105 }
5106 /* else treat it as a constant */
5107 }
5108 }
5117 {
5118 /*
5119 * We have an expression in vars of a single relation. Try to match
5120 * it to expressional index columns, in hopes of finding some
5121 * statistics.
5122 *
5123 * Note that we consider all index columns including INCLUDE columns,
5124 * since there could be stats for such columns. But the test for
5125 * uniqueness needs to be warier.
5126 *
5127 * XXX it's conceivable that there are multiple matches with different
5128 * index opfamilies; if so, we need to pick one that matches the
5129 * operator we are estimating for. FIXME later.
5130 */
5133 Oid userid;
5135 /*
5136 * Determine the user ID to use for privilege checks: either
5137 * onerel->userid if it's set (e.g., in case we're accessing the table
5138 * via a view), or the current user otherwise.
5139 *
5140 * If we drill down to child relations, we keep using the same userid:
5141 * it's going to be the same anyway, due to how we set up the relation
5142 * tree (q.v. build_simple_rel).
5143 */
5147 {
5157 {
5159 {
5168 {
5169 /*
5170 * Found a match ... is it a unique index? Tests here
5171 * should match has_unique_index().
5172 */
5179 /*
5180 * Has it got stats? We only consider stats for
5181 * non-partial indexes, since partial indexes probably
5182 * don't reflect whole-relation statistics; the above
5183 * check for uniqueness is the only info we take from
5184 * a partial index.
5185 *
5186 * An index stats hook, however, must make its own
5187 * decisions about what to do with partial indexes.
5188 */
5192 {
5193 /*
5194 * The hook took control of acquiring a stats
5195 * tuple. If it did supply a tuple, it'd better
5196 * have supplied a freefunc.
5197 */
5201 }
5203 {
5212 {
5213 /* Get index's table for permission check */
5219 /*
5220 * For simplicity, we insist on the whole
5221 * table being selectable, rather than trying
5222 * to identify which column(s) the index
5223 * depends on. Also require all rows to be
5224 * selectable --- there must be no
5225 * securityQuals from security barrier views
5226 * or RLS policies.
5227 */
5233 /*
5234 * If the user doesn't have permissions to
5235 * access an inheritance child relation, check
5236 * the permissions of the table actually
5237 * mentioned in the query, since most likely
5238 * the user does have that permission. Note
5239 * that whole-table select privilege on the
5240 * parent doesn't quite guarantee that the
5241 * user could read all columns of the child.
5242 * But in practice it's unlikely that any
5243 * interesting security violation could result
5244 * from allowing access to the expression
5245 * index's stats, so we allow it anyway. See
5246 * similar code in examine_simple_variable()
5247 * for additional comments.
5248 */
5251 {
5259 {
5262 }
5264 {
5265 /* Repeat access check on this rel */
5272 userid,
5274 }
5275 }
5276 }
5277 else
5278 {
5279 /* suppress leakproofness checks later */
5281 }
5282 }
5285 }
5287 }
5288 }
5291 }
5293 /*
5294 * Search extended statistics for one with a matching expression.
5295 * There might be multiple ones, so just grab the first one. In the
5296 * future, we might consider the statistics target (and pick the most
5297 * accurate statistics) and maybe some other parameters.
5298 */
5300 {
5306 /*
5307 * Stop once we've found statistics for the expression (either
5308 * from extended stats, or for an index in the preceding loop).
5309 */
5313 /* skip stats without per-expression stats */
5317 /* skip stats with mismatching stxdinherit value */
5323 {
5328 /* strip RelabelType before comparing it */
5332 /* found a match, see if we can extract pg_statistic row */
5334 {
5335 /*
5336 * XXX Not sure if we should cache the tuple somewhere.
5337 * Now we just create a new copy every time.
5338 */
5344 /*
5345 * For simplicity, we insist on the whole table being
5346 * selectable, rather than trying to identify which
5347 * column(s) the statistics object depends on. Also
5348 * require all rows to be selectable --- there must be no
5349 * securityQuals from security barrier views or RLS
5350 * policies.
5351 */
5357 /*
5358 * If the user doesn't have permissions to access an
5359 * inheritance child relation, check the permissions of
5360 * the table actually mentioned in the query, since most
5361 * likely the user does have that permission. Note that
5362 * whole-table select privilege on the parent doesn't
5363 * quite guarantee that the user could read all columns of
5364 * the child. But in practice it's unlikely that any
5365 * interesting security violation could result from
5366 * allowing access to the expression stats, so we allow it
5367 * anyway. See similar code in examine_simple_variable()
5368 * for additional comments.
5369 */
5372 {
5380 {
5383 }
5385 {
5386 /* Repeat access check on this rel */
5393 userid,
5395 }
5396 }
5399 }
5401 pos++;
5402 }
5403 }
5404 }
5405 }
5407 /*
5408 * examine_simple_variable
5409 * Handle a simple Var for examine_variable
5410 *
5411 * This is split out as a subroutine so that we can recurse to deal with
5412 * Vars referencing subqueries (either sub-SELECT-in-FROM or CTE style).
5413 *
5414 * We already filled in all the fields of *vardata except for the stats tuple.
5415 */
5416 static void
5419 {
5426 {
5427 /*
5428 * The hook took control of acquiring a stats tuple. If it did supply
5429 * a tuple, it'd better have supplied a freefunc.
5430 */
5434 }
5436 {
5437 /*
5438 * Plain table or parent of an inheritance appendrel, so look up the
5439 * column in pg_statistic
5440 */
5448 {
5450 Oid userid;
5452 /*
5453 * Check if user has permission to read this column. We require
5454 * all rows to be accessible, so there must be no securityQuals
5455 * from security barrier views or RLS policies.
5456 *
5457 * Normally the Var will have an associated RelOptInfo from which
5458 * we can find out which userid to do the check as; but it might
5459 * not if it's a RETURNING Var for an INSERT target relation. In
5460 * that case use the RTEPermissionInfo associated with the RTE.
5461 */
5464 else
5465 {
5470 }
5481 /*
5482 * If the user doesn't have permissions to access an inheritance
5483 * child relation or specifically this attribute, check the
5484 * permissions of the table/column actually mentioned in the
5485 * query, since most likely the user does have that permission
5486 * (else the query will fail at runtime), and if the user can read
5487 * the column there then he can get the values of the child table
5488 * too. To do that, we must find out which of the root parent's
5489 * attributes the child relation's attribute corresponds to.
5490 */
5493 {
5501 /*
5502 * Partitions are mapped to their immediate parent, not the
5503 * root parent, so must be ready to walk up multiple
5504 * AppendRelInfos. But stop if we hit a parent that is not
5505 * RTE_RELATION --- that's a flattened UNION ALL subquery, not
5506 * an inheritance parent.
5507 */
5511 {
5525 /* If the parent is itself a child, continue up. */
5527 }
5529 /*
5530 * In rare cases, the Var may be local to the child table, in
5531 * which case, we've got to live with having no access to this
5532 * column's stats.
5533 */
5537 /* Repeat the access check on this parent rel & column */
5541 /*
5542 * Fine to use the same userid as it's the same in all
5543 * relations of a given inheritance tree.
5544 */
5551 }
5552 }
5553 else
5554 {
5555 /* suppress any possible leakproofness checks later */
5557 }
5558 }
5561 {
5562 /*
5563 * Plain subquery (not one that was converted to an appendrel) or
5564 * non-recursive CTE. In either case, we can try to find out what the
5565 * Var refers to within the subquery. We skip this for appendrel and
5566 * recursive-CTE cases because any column stats we did find would
5567 * likely not be very relevant.
5568 */
5574 /*
5575 * Punt if it's a whole-row var rather than a plain column reference.
5576 */
5580 /*
5581 * Otherwise, find the subquery's planner subroot.
5582 */
5584 {
5587 /*
5588 * Fetch RelOptInfo for subquery. Note that we don't change the
5589 * rel returned in vardata, since caller expects it to be a rel of
5590 * the caller's query level. Because we might already be
5591 * recursing, we can't use that rel pointer either, but have to
5592 * look up the Var's rel afresh.
5593 */
5597 }
5598 else
5599 {
5600 /* CTE case is more difficult */
5602 Index levelsup;
5607 /*
5608 * Find the referenced CTE, and locate the subroot previously made
5609 * for it.
5610 */
5614 {
5618 }
5620 /*
5621 * Note: cte_plan_ids can be shorter than cteList, if we are still
5622 * working on planning the CTEs (ie, this is a side-reference from
5623 * another CTE). So we mustn't use forboth here.
5624 */
5627 {
5632 ndx++;
5633 }
5642 }
5644 /* If the subquery hasn't been planned yet, we have to punt */
5649 /*
5650 * We must use the subquery parsetree as mangled by the planner, not
5651 * the raw version from the RTE, because we need a Var that will refer
5652 * to the subroot's live RelOptInfos. For instance, if any subquery
5653 * pullup happened during planning, Vars in the targetlist might have
5654 * gotten replaced, and we need to see the replacement expressions.
5655 */
5659 /*
5660 * Punt if subquery uses set operations or GROUP BY, as these will
5661 * mash underlying columns' stats beyond recognition. (Set ops are
5662 * particularly nasty; if we forged ahead, we would return stats
5663 * relevant to only the leftmost subselect...) DISTINCT is also
5664 * problematic, but we check that later because there is a possibility
5665 * of learning something even with it.
5666 */
5672 /* Get the subquery output expression referenced by the upper Var */
5675 else
5683 /*
5684 * If subquery uses DISTINCT, we can't make use of any stats for the
5685 * variable ... but, if it's the only DISTINCT column, we are entitled
5686 * to consider it unique. We do the test this way so that it works
5687 * for cases involving DISTINCT ON.
5688 */
5690 {
5694 /* cannot go further */
5696 }
5698 /*
5699 * If the sub-query originated from a view with the security_barrier
5700 * attribute, we must not look at the variable's statistics, though it
5701 * seems all right to notice the existence of a DISTINCT clause. So
5702 * stop here.
5703 *
5704 * This is probably a harsher restriction than necessary; it's
5705 * certainly OK for the selectivity estimator (which is a C function,
5706 * and therefore omnipotent anyway) to look at the statistics. But
5707 * many selectivity estimators will happily *invoke the operator
5708 * function* to try to work out a good estimate - and that's not OK.
5709 * So for now, don't dig down for stats.
5710 */
5714 /* Can only handle a simple Var of subquery's query level */
5717 {
5718 /*
5719 * OK, recurse into the subquery. Note that the original setting
5720 * of vardata->isunique (which will surely be false) is left
5721 * unchanged in this situation. That's what we want, since even
5722 * if the underlying column is unique, the subquery may have
5723 * joined to other tables in a way that creates duplicates.
5724 */
5726 }
5727 }
5728 else
5729 {
5730 /*
5731 * Otherwise, the Var comes from a FUNCTION or VALUES RTE. (We won't
5732 * see RTE_JOIN here because join alias Vars have already been
5733 * flattened.) There's not much we can do with function outputs, but
5734 * maybe someday try to be smarter about VALUES.
5735 */
5736 }
5737 }
5739 /*
5740 * Check whether it is permitted to call func_oid passing some of the
5741 * pg_statistic data in vardata. We allow this either if the user has SELECT
5742 * privileges on the table or column underlying the pg_statistic data or if
5743 * the function is marked leak-proof.
5744 */
5745 bool
5747 {
5761 }
5763 /*
5764 * get_variable_numdistinct
5765 * Estimate the number of distinct values of a variable.
5766 *
5767 * vardata: results of examine_variable
5768 * *isdefault: set to true if the result is a default rather than based on
5769 * anything meaningful.
5770 *
5771 * NB: be careful to produce a positive integral result, since callers may
5772 * compare the result to exact integer counts, or might divide by it.
5773 */
5774 double
5776 {
5783 /*
5784 * Determine the stadistinct value to use. There are cases where we can
5785 * get an estimate even without a pg_statistic entry, or can get a better
5786 * value than is in pg_statistic. Grab stanullfrac too if we can find it
5787 * (otherwise, assume no nulls, for lack of any better idea).
5788 */
5790 {
5791 /* Use the pg_statistic entry */
5792 Form_pg_statistic stats;
5797 }
5799 {
5800 /*
5801 * Special-case boolean columns: presumably, two distinct values.
5802 *
5803 * Are there any other datatypes we should wire in special estimates
5804 * for?
5805 */
5807 }
5809 {
5810 /*
5811 * If the Var represents a column of a VALUES RTE, assume it's unique.
5812 * This could of course be very wrong, but it should tend to be true
5813 * in well-written queries. We could consider examining the VALUES'
5814 * contents to get some real statistics; but that only works if the
5815 * entries are all constants, and it would be pretty expensive anyway.
5816 */
5818 }
5819 else
5820 {
5821 /*
5822 * We don't keep statistics for system columns, but in some cases we
5823 * can infer distinctness anyway.
5824 */
5826 {
5828 {
5838 }
5839 }
5840 else
5843 /*
5844 * XXX consider using estimate_num_groups on expressions?
5845 */
5846 }
5848 /*
5849 * If there is a unique index or DISTINCT clause for the variable, assume
5850 * it is unique no matter what pg_statistic says; the statistics could be
5851 * out of date, or we might have found a partial unique index that proves
5852 * the var is unique for this query. However, we'd better still believe
5853 * the null-fraction statistic.
5854 */
5858 /*
5859 * If we had an absolute estimate, use that.
5860 */
5864 /*
5865 * Otherwise we need to get the relation size; punt if not available.
5866 */
5868 {
5871 }
5874 {
5877 }
5879 /*
5880 * If we had a relative estimate, use that.
5881 */
5885 /*
5886 * With no data, estimate ndistinct = ntuples if the table is small, else
5887 * use default. We use DEFAULT_NUM_DISTINCT as the cutoff for "small" so
5888 * that the behavior isn't discontinuous.
5889 */
5895 }
5897 /*
5898 * get_variable_range
5899 * Estimate the minimum and maximum value of the specified variable.
5900 * If successful, store values in *min and *max, and return true.
5901 * If no data available, return false.
5902 *
5903 * sortop is the "<" comparison operator to use. This should generally
5904 * be "<" not ">", as only the former is likely to be found in pg_statistic.
5905 * The collation must be specified too.
5906 */
5907 static bool
5911 {
5915 int16 typLen;
5917 Oid opfuncoid;
5918 FmgrInfo opproc;
5919 AttStatsSlot sslot;
5921 /*
5922 * XXX It's very tempting to try to use the actual column min and max, if
5923 * we can get them relatively-cheaply with an index probe. However, since
5924 * this function is called many times during join planning, that could
5925 * have unpleasant effects on planning speed. Need more investigation
5926 * before enabling this.
5927 */
5928 #ifdef NOT_USED
5931 #endif
5934 {
5935 /* no stats available, so default result */
5937 }
5939 /*
5940 * If we can't apply the sortop to the stats data, just fail. In
5941 * principle, if there's a histogram and no MCVs, we could return the
5942 * histogram endpoints without ever applying the sortop ... but it's
5943 * probably not worth trying, because whatever the caller wants to do with
5944 * the endpoints would likely fail the security check too.
5945 */
5954 /*
5955 * If there is a histogram with the ordering we want, grab the first and
5956 * last values.
5957 */
5960 ATTSTATSSLOT_VALUES))
5961 {
5963 {
5967 }
5969 }
5971 /*
5972 * Otherwise, if there is a histogram with some other ordering, scan it
5973 * and get the min and max values according to the ordering we want. This
5974 * of course may not find values that are really extremal according to our
5975 * ordering, but it beats ignoring available data.
5976 */
5980 ATTSTATSSLOT_VALUES))
5981 {
5986 }
5988 /*
5989 * If we have most-common-values info, look for extreme MCVs. This is
5990 * needed even if we also have a histogram, since the histogram excludes
5991 * the MCVs. However, if we *only* have MCVs and no histogram, we should
5992 * be pretty wary of deciding that that is a full representation of the
5993 * data. Proceed only if the MCVs represent the whole table (to within
5994 * roundoff error).
5995 */
6000 {
6004 {
6014 }
6021 }
6026 }
6028 /*
6029 * get_stats_slot_range: scan sslot for min/max values
6030 *
6031 * Subroutine for get_variable_range: update min/max/have_data according
6032 * to what we find in the statistics array.
6033 */
6034 static void
6038 {
6045 /* Look up the comparison function, if we didn't already do so */
6049 /* Scan all the slot's values */
6051 {
6053 {
6058 }
6060 collation,
6062 {
6065 }
6067 collation,
6069 {
6072 }
6073 }
6075 /*
6076 * Copy the slot's values, if we found new extreme values.
6077 */
6082 }
6085 /*
6086 * get_actual_variable_range
6087 * Attempt to identify the current *actual* minimum and/or maximum
6088 * of the specified variable, by looking for a suitable btree index
6089 * and fetching its low and/or high values.
6090 * If successful, store values in *min and *max, and return true.
6091 * (Either pointer can be NULL if that endpoint isn't needed.)
6092 * If unsuccessful, return false.
6093 *
6094 * sortop is the "<" comparison operator to use.
6095 * collation is the required collation.
6096 */
6097 static bool
6101 {
6107 /* No hope if no relation or it doesn't have indexes */
6110 /* If it has indexes it must be a plain relation */
6114 /* ignore partitioned tables. Any indexes here are not real indexes */
6118 /* Search through the indexes to see if any match our problem */
6120 {
6122 ScanDirection indexscandir;
6124 /* Ignore non-btree indexes */
6128 /*
6129 * Ignore partial indexes --- we only want stats that cover the entire
6130 * relation.
6131 */
6135 /*
6136 * The index list might include hypothetical indexes inserted by a
6137 * get_relation_info hook --- don't try to access them.
6138 */
6142 /*
6143 * The first index column must match the desired variable, sortop, and
6144 * collation --- but we can use a descending-order index.
6145 */
6151 {
6155 else
6161 else
6165 /* index doesn't match the sortop */
6167 }
6169 /*
6170 * Found a suitable index to extract data from. Set up some data that
6171 * can be used by both invocations of get_actual_variable_endpoint.
6172 */
6173 {
6174 MemoryContext tmpcontext;
6175 MemoryContext oldcontext;
6176 Relation heapRel;
6177 Relation indexRel;
6179 int16 typLen;
6183 /* Make sure any cruft gets recycled when we're done */
6186 ALLOCSET_DEFAULT_SIZES);
6189 /*
6190 * Open the table and index so we can read from them. We should
6191 * already have some type of lock on each.
6192 */
6196 /* build some stuff needed for indexscan execution */
6200 /* set up an IS NOT NULL scan key so that we ignore nulls */
6210 /* If min is requested ... */
6212 {
6214 indexRel,
6215 indexscandir,
6216 scankeys,
6217 typLen,
6218 typByVal,
6219 slot,
6220 oldcontext,
6221 min);
6222 }
6223 else
6224 {
6225 /* If min not requested, still want to fetch max */
6227 }
6229 /* If max is requested, and we didn't already fail ... */
6231 {
6232 /* scan in the opposite direction; all else is the same */
6234 indexRel,
6236 scankeys,
6237 typLen,
6238 typByVal,
6239 slot,
6240 oldcontext,
6241 max);
6242 }
6244 /* Clean everything up */
6253 /* And we're done */
6255 }
6256 }
6259 }
6261 /*
6262 * Get one endpoint datum (min or max depending on indexscandir) from the
6263 * specified index. Return true if successful, false if not.
6264 * On success, endpoint value is stored to *endpointDatum (and copied into
6265 * outercontext).
6266 *
6267 * scankeys is a 1-element scankey array set up to reject nulls.
6268 * typLen/typByVal describe the datatype of the index's first column.
6269 * tableslot is a slot suitable to hold table tuples, in case we need
6270 * to probe the heap.
6271 * (We could compute these values locally, but that would mean computing them
6272 * twice when get_actual_variable_range needs both the min and the max.)
6273 *
6274 * Failure occurs either when the index is empty, or we decide that it's
6275 * taking too long to find a suitable tuple.
6276 */
6277 static bool
6279 Relation indexRel,
6280 ScanDirection indexscandir,
6281 ScanKey scankeys,
6282 int16 typLen,
6285 MemoryContext outercontext,
6287 {
6289 SnapshotData SnapshotNonVacuumable;
6290 IndexScanDesc index_scan;
6294 ItemPointer tid;
6297 MemoryContext oldcontext;
6299 /*
6300 * We use the index-only-scan machinery for this. With mostly-static
6301 * tables that's a win because it avoids a heap visit. It's also a win
6302 * for dynamic data, but the reason is less obvious; read on for details.
6303 *
6304 * In principle, we should scan the index with our current active
6305 * snapshot, which is the best approximation we've got to what the query
6306 * will see when executed. But that won't be exact if a new snap is taken
6307 * before running the query, and it can be very expensive if a lot of
6308 * recently-dead or uncommitted rows exist at the beginning or end of the
6309 * index (because we'll laboriously fetch each one and reject it).
6310 * Instead, we use SnapshotNonVacuumable. That will accept recently-dead
6311 * and uncommitted rows as well as normal visible rows. On the other
6312 * hand, it will reject known-dead rows, and thus not give a bogus answer
6313 * when the extreme value has been deleted (unless the deletion was quite
6314 * recent); that case motivates not using SnapshotAny here.
6315 *
6316 * A crucial point here is that SnapshotNonVacuumable, with
6317 * GlobalVisTestFor(heapRel) as horizon, yields the inverse of the
6318 * condition that the indexscan will use to decide that index entries are
6319 * killable (see heap_hot_search_buffer()). Therefore, if the snapshot
6320 * rejects a tuple (or more precisely, all tuples of a HOT chain) and we
6321 * have to continue scanning past it, we know that the indexscan will mark
6322 * that index entry killed. That means that the next
6323 * get_actual_variable_endpoint() call will not have to re-consider that
6324 * index entry. In this way we avoid repetitive work when this function
6325 * is used a lot during planning.
6326 *
6327 * But using SnapshotNonVacuumable creates a hazard of its own. In a
6328 * recently-created index, some index entries may point at "broken" HOT
6329 * chains in which not all the tuple versions contain data matching the
6330 * index entry. The live tuple version(s) certainly do match the index,
6331 * but SnapshotNonVacuumable can accept recently-dead tuple versions that
6332 * don't match. Hence, if we took data from the selected heap tuple, we
6333 * might get a bogus answer that's not close to the index extremal value,
6334 * or could even be NULL. We avoid this hazard because we take the data
6335 * from the index entry not the heap.
6336 *
6337 * Despite all this care, there are situations where we might find many
6338 * non-visible tuples near the end of the index. We don't want to expend
6339 * a huge amount of time here, so we give up once we've read too many heap
6340 * pages. When we fail for that reason, the caller will end up using
6341 * whatever extremal value is recorded in pg_statistic.
6342 */
6349 /* Set it up for index-only scan */
6353 /* Fetch first/next tuple in specified direction */
6355 {
6359 block,
6361 {
6362 /* Rats, we have to visit the heap to check visibility */
6364 {
6365 /*
6366 * No visible tuple for this index entry, so we need to
6367 * advance to the next entry. Before doing so, count heap
6368 * page fetches and give up if we've done too many.
6369 *
6370 * We don't charge a page fetch if this is the same heap page
6371 * as the previous tuple. This is on the conservative side,
6372 * since other recently-accessed pages are probably still in
6373 * buffers too; but it's good enough for this heuristic.
6374 */
6375 #define VISITED_PAGES_LIMIT 100
6378 {
6380 n_visited_heap_pages++;
6383 }
6386 }
6388 /* We don't actually need the heap tuple for anything */
6391 /*
6392 * We don't care whether there's more than one visible tuple in
6393 * the HOT chain; if any are visible, that's good enough.
6394 */
6395 }
6397 /*
6398 * We expect that btree will return data in IndexTuple not HeapTuple
6399 * format. It's not lossy either.
6400 */
6406 /* OK to deconstruct the index tuple */
6411 /* Shouldn't have got a null, but be careful */
6416 /* Copy the index column value out to caller's context */
6422 }
6429 }
6431 /*
6432 * find_join_input_rel
6433 * Look up the input relation for a join.
6434 *
6435 * We assume that the input relation's RelOptInfo must have been constructed
6436 * already.
6437 */
6440 {
6444 {
6449 else
6451 }
6457 }
6460 /*-------------------------------------------------------------------------
6461 *
6462 * Index cost estimation functions
6463 *
6464 *-------------------------------------------------------------------------
6465 */
6467 /*
6468 * Extract the actual indexquals (as RestrictInfos) from an IndexClause list
6469 */
6470 List *
6472 {
6477 {
6482 {
6486 }
6487 }
6489 }
6491 /*
6492 * Compute the total evaluation cost of the comparison operands in a list
6493 * of index qual expressions. Since we know these will be evaluated just
6494 * once per scan, there's no need to distinguish startup from per-row cost.
6495 *
6496 * This can be used either on the result of get_quals_from_indexclauses(),
6497 * or directly on an indexorderbys list. In both cases, we expect that the
6498 * index key expression is on the left side of binary clauses.
6499 */
6500 Cost
6502 {
6507 {
6510 QualCost index_qual_cost;
6512 /*
6513 * Index quals will have RestrictInfos, indexorderbys won't. Look
6514 * through RestrictInfo if present.
6515 */
6520 {
6524 }
6526 {
6530 }
6532 {
6536 }
6538 {
6540 }
6541 else
6542 {
6546 }
6550 }
6552 }
6554 void
6559 {
6563 Cost indexStartupCost;
6564 Cost indexTotalCost;
6565 Selectivity indexSelectivity;
6578 /*
6579 * If the index is partial, AND the index predicate with the explicitly
6580 * given indexquals to produce a more accurate idea of the index
6581 * selectivity.
6582 */
6585 /*
6586 * If caller didn't give us an estimate for ScalarArrayOpExpr index scans,
6587 * just assume that the number of index descents is the number of distinct
6588 * combinations of array elements from all of the scan's SAOP clauses.
6589 */
6592 {
6595 {
6599 {
6605 }
6606 }
6607 }
6609 /* Estimate the fraction of main-table tuples that will be visited */
6612 JOIN_INNER,
6613 NULL);
6615 /*
6616 * If caller didn't give us an estimate, estimate the number of index
6617 * tuples that will be visited. We do it in this rather peculiar-looking
6618 * way in order to get the right answer for partial indexes.
6619 */
6622 {
6625 /*
6626 * The above calculation counts all the tuples visited across all
6627 * scans induced by ScalarArrayOpExpr nodes. We want to consider the
6628 * average per-indexscan number, so adjust. This is a handy place to
6629 * round to integer, too. (If caller supplied tuple estimate, it's
6630 * responsible for handling these considerations.)
6631 */
6633 }
6635 /*
6636 * We can bound the number of tuples by the index size in any case. Also,
6637 * always estimate at least one tuple is touched, even when
6638 * indexSelectivity estimate is tiny.
6639 */
6645 /*
6646 * Estimate the number of index pages that will be retrieved.
6647 *
6648 * We use the simplistic method of taking a pro-rata fraction of the total
6649 * number of index pages. In effect, this counts only leaf pages and not
6650 * any overhead such as index metapage or upper tree levels.
6651 *
6652 * In practice access to upper index levels is often nearly free because
6653 * those tend to stay in cache under load; moreover, the cost involved is
6654 * highly dependent on index type. We therefore ignore such costs here
6655 * and leave it to the caller to add a suitable charge if needed.
6656 */
6659 else
6662 /* fetch estimated page cost for tablespace containing index */
6665 NULL);
6667 /*
6668 * Now compute the disk access costs.
6669 *
6670 * The above calculations are all per-index-scan. However, if we are in a
6671 * nestloop inner scan, we can expect the scan to be repeated (with
6672 * different search keys) for each row of the outer relation. Likewise,
6673 * ScalarArrayOpExpr quals result in multiple index scans. This creates
6674 * the potential for cache effects to reduce the number of disk page
6675 * fetches needed. We want to estimate the average per-scan I/O cost in
6676 * the presence of caching.
6677 *
6678 * We use the Mackert-Lohman formula (see costsize.c for details) to
6679 * estimate the total number of page fetches that occur. While this
6680 * wasn't what it was designed for, it seems a reasonable model anyway.
6681 * Note that we are counting pages not tuples anymore, so we take N = T =
6682 * index size, as if there were one "tuple" per page.
6683 */
6688 {
6691 /* total page fetches ignoring cache effects */
6694 /* use Mackert and Lohman formula to adjust for cache effects */
6698 root);
6700 /*
6701 * Now compute the total disk access cost, and then report a pro-rated
6702 * share for each outer scan. (Don't pro-rate for ScalarArrayOpExpr,
6703 * since that's internal to the indexscan.)
6704 */
6707 }
6708 else
6709 {
6710 /*
6711 * For a single index scan, we just charge spc_random_page_cost per
6712 * page touched.
6713 */
6715 }
6717 /*
6718 * CPU cost: any complex expressions in the indexquals will need to be
6719 * evaluated once at the start of the scan to reduce them to runtime keys
6720 * to pass to the index AM (see nodeIndexscan.c). We model the per-tuple
6721 * CPU costs as cpu_index_tuple_cost plus one cpu_operator_cost per
6722 * indexqual operator. Because we have numIndexTuples as a per-scan
6723 * number, we have to multiply by num_sa_scans to get the correct result
6724 * for ScalarArrayOpExpr cases. Similarly add in costs for any index
6725 * ORDER BY expressions.
6726 *
6727 * Note: this neglects the possible costs of rechecking lossy operators.
6728 * Detecting that that might be needed seems more expensive than it's
6729 * worth, though, considering all the other inaccuracies here ...
6730 */
6740 /*
6741 * Generic assumption about index correlation: there isn't any.
6742 */
6745 /*
6746 * Return everything to caller.
6747 */
6756 }
6758 /*
6759 * If the index is partial, add its predicate to the given qual list.
6760 *
6761 * ANDing the index predicate with the explicitly given indexquals produces
6762 * a more accurate idea of the index's selectivity. However, we need to be
6763 * careful not to insert redundant clauses, because clauselist_selectivity()
6764 * is easily fooled into computing a too-low selectivity estimate. Our
6765 * approach is to add only the predicate clause(s) that cannot be proven to
6766 * be implied by the given indexquals. This successfully handles cases such
6767 * as a qual "x = 42" used with a partial index "WHERE x >= 40 AND x < 50".
6768 * There are many other cases where we won't detect redundancy, leading to a
6769 * too-low selectivity estimate, which will bias the system in favor of using
6770 * partial indexes where possible. That is not necessarily bad though.
6771 *
6772 * Note that indexQuals contains RestrictInfo nodes while the indpred
6773 * does not, so the output list will be mixed. This is OK for both
6774 * predicate_implied_by() and clauselist_selectivity(), but might be
6775 * problematic if the result were passed to other things.
6776 */
6777 List *
6779 {
6787 {
6793 }
6795 }
6798 void
6803 {
6806 Oid relid;
6807 AttrNumber colnum;
6810 Cost descentCost;
6819 /*
6820 * For a btree scan, only leading '=' quals plus inequality quals for the
6821 * immediately next attribute contribute to index selectivity (these are
6822 * the "boundary quals" that determine the starting and stopping points of
6823 * the index scan). Additional quals can suppress visits to the heap, so
6824 * it's OK to count them in indexSelectivity, but they should not count
6825 * for estimating numIndexTuples. So we must examine the given indexquals
6826 * to find out which ones count as boundary quals. We rely on the
6827 * knowledge that they are given in index column order.
6828 *
6829 * For a RowCompareExpr, we consider only the first column, just as
6830 * rowcomparesel() does.
6831 *
6832 * If there's a ScalarArrayOpExpr in the quals, we'll actually perform up
6833 * to N index descents (not just one), but the ScalarArrayOpExpr's
6834 * operator can be considered to act the same as it normally does.
6835 */
6843 {
6848 {
6849 /* Beginning of a new column's quals */
6853 indexcol++;
6856 }
6858 /* Examine each indexqual associated with this index clause */
6860 {
6867 {
6871 }
6873 {
6877 }
6879 {
6886 /* estimate SA descents by indexBoundQuals only */
6889 }
6891 {
6895 {
6897 /* IS NULL is like = for selectivity purposes */
6899 }
6900 }
6901 else
6905 /* check for equality operator */
6907 {
6913 }
6916 }
6917 }
6919 /*
6920 * If index is unique and we found an '=' clause for each column, we can
6921 * just assume numIndexTuples = 1 and skip the expensive
6922 * clauselist_selectivity calculations. However, a ScalarArrayOp or
6923 * NullTest invalidates that theory, even though it sets eqQualHere.
6924 */
6927 eqQualHere &&
6931 else
6932 {
6934 Selectivity btreeSelectivity;
6936 /*
6937 * If the index is partial, AND the index predicate with the
6938 * index-bound quals to produce a more accurate idea of the number of
6939 * rows covered by the bound conditions.
6940 */
6945 JOIN_INNER,
6946 NULL);
6949 /*
6950 * btree automatically combines individual ScalarArrayOpExpr primitive
6951 * index scans whenever the tuples covered by the next set of array
6952 * keys are close to tuples covered by the current set. That puts a
6953 * natural ceiling on the worst case number of descents -- there
6954 * cannot possibly be more than one descent per leaf page scanned.
6955 *
6956 * Clamp the number of descents to at most 1/3 the number of index
6957 * pages. This avoids implausibly high estimates with low selectivity
6958 * paths, where scans usually require only one or two descents. This
6959 * is most likely to help when there are several SAOP clauses, where
6960 * naively accepting the total number of distinct combinations of
6961 * array elements as the number of descents would frequently lead to
6962 * wild overestimates.
6963 *
6964 * We somewhat arbitrarily don't just make the cutoff the total number
6965 * of leaf pages (we make it 1/3 the total number of pages instead) to
6966 * give the btree code credit for its ability to continue on the leaf
6967 * level with low selectivity scans.
6968 */
6972 /*
6973 * As in genericcostestimate(), we have to adjust for any
6974 * ScalarArrayOpExpr quals included in indexBoundQuals, and then round
6975 * to integer.
6976 *
6977 * It is tempting to make genericcostestimate behave as if SAOP
6978 * clauses work in almost the same way as scalar operators during
6979 * btree scans, making the top-level scan look like a continuous scan
6980 * (as opposed to num_sa_scans-many primitive index scans). After
6981 * all, btree scans mostly work like that at runtime. However, such a
6982 * scheme would badly bias genericcostestimate's simplistic approach
6983 * to calculating numIndexPages through prorating.
6984 *
6985 * Stick with the approach taken by non-native SAOP scans for now.
6986 * genericcostestimate will use the Mackert-Lohman formula to
6987 * compensate for repeat page fetches, even though that definitely
6988 * won't happen during btree scans (not for leaf pages, at least).
6989 * We're usually very pessimistic about the number of primitive index
6990 * scans that will be required, but it's not clear how to do better.
6991 */
6993 }
6995 /*
6996 * Now do generic index cost estimation.
6997 */
7003 /*
7004 * Add a CPU-cost component to represent the costs of initial btree
7005 * descent. We don't charge any I/O cost for touching upper btree levels,
7006 * since they tend to stay in cache, but we still have to do about log2(N)
7007 * comparisons to descend a btree of N leaf tuples. We charge one
7008 * cpu_operator_cost per comparison.
7009 *
7010 * If there are ScalarArrayOpExprs, charge this once per estimated SA
7011 * index descent. The ones after the first one are not startup cost so
7012 * far as the overall plan goes, so just add them to "total" cost.
7013 */
7015 {
7019 }
7021 /*
7022 * Even though we're not charging I/O cost for touching upper btree pages,
7023 * it's still reasonable to charge some CPU cost per page descended
7024 * through. Moreover, if we had no such charge at all, bloated indexes
7025 * would appear to have the same search cost as unbloated ones, at least
7026 * in cases where only a single leaf page is expected to be visited. This
7027 * cost is somewhat arbitrarily set at 50x cpu_operator_cost per page
7028 * touched. The number of such pages is btree tree height plus one (ie,
7029 * we charge for the leaf page too). As above, charge once per estimated
7030 * SA index descent.
7031 */
7036 /*
7037 * If we can get an estimate of the first column's ordering correlation C
7038 * from pg_statistic, estimate the index correlation as C for a
7039 * single-column index, or C * 0.75 for multiple columns. (The idea here
7040 * is that multiple columns dilute the importance of the first column's
7041 * ordering, but don't negate it entirely. Before 8.0 we divided the
7042 * correlation by the number of columns, but that seems too strong.)
7043 */
7045 {
7046 /* Simple variable --- look to stats for the underlying table */
7056 {
7057 /*
7058 * The hook took control of acquiring a stats tuple. If it did
7059 * supply a tuple, it'd better have supplied a freefunc.
7060 */
7064 }
7065 else
7066 {
7072 }
7073 }
7074 else
7075 {
7076 /* Expression --- maybe there are stats for the index itself */
7082 {
7083 /*
7084 * The hook took control of acquiring a stats tuple. If it did
7085 * supply a tuple, it'd better have supplied a freefunc.
7086 */
7090 }
7091 else
7092 {
7098 }
7099 }
7102 {
7103 Oid sortop;
7104 AttStatsSlot sslot;
7109 BTLessStrategyNumber);
7113 ATTSTATSSLOT_NUMBERS))
7114 {
7125 else
7129 }
7130 }
7139 }
7141 void
7146 {
7151 /*
7152 * A hash index has no descent costs as such, since the index AM can go
7153 * directly to the target bucket after computing the hash value. There
7154 * are a couple of other hash-specific costs that we could conceivably add
7155 * here, though:
7156 *
7157 * Ideally we'd charge spc_random_page_cost for each page in the target
7158 * bucket, not just the numIndexPages pages that genericcostestimate
7159 * thought we'd visit. However in most cases we don't know which bucket
7160 * that will be. There's no point in considering the average bucket size
7161 * because the hash AM makes sure that's always one page.
7162 *
7163 * Likewise, we could consider charging some CPU for each index tuple in
7164 * the bucket, if we knew how many there were. But the per-tuple cost is
7165 * just a hash value comparison, not a general datatype-dependent
7166 * comparison, so any such charge ought to be quite a bit less than
7167 * cpu_operator_cost; which makes it probably not worth worrying about.
7168 *
7169 * A bigger issue is that chance hash-value collisions will result in
7170 * wasted probes into the heap. We don't currently attempt to model this
7171 * cost on the grounds that it's rare, but maybe it's not rare enough.
7172 * (Any fix for this ought to consider the generic lossy-operator problem,
7173 * though; it's not entirely hash-specific.)
7174 */
7181 }
7183 void
7188 {
7191 Cost descentCost;
7195 /*
7196 * We model index descent costs similarly to those for btree, but to do
7197 * that we first need an idea of the tree height. We somewhat arbitrarily
7198 * assume that the fanout is 100, meaning the tree height is at most
7199 * log100(index->pages).
7200 *
7201 * Although this computation isn't really expensive enough to require
7202 * caching, we might as well use index->tree_height to cache it.
7203 */
7205 {
7208 else
7210 }
7212 /*
7213 * Add a CPU-cost component to represent the costs of initial descent. We
7214 * just use log(N) here not log2(N) since the branching factor isn't
7215 * necessarily two anyway. As for btree, charge once per SA scan.
7216 */
7218 {
7222 }
7224 /*
7225 * Likewise add a per-page charge, calculated the same as for btrees.
7226 */
7236 }
7238 void
7243 {
7246 Cost descentCost;
7250 /*
7251 * We model index descent costs similarly to those for btree, but to do
7252 * that we first need an idea of the tree height. We somewhat arbitrarily
7253 * assume that the fanout is 100, meaning the tree height is at most
7254 * log100(index->pages).
7255 *
7256 * Although this computation isn't really expensive enough to require
7257 * caching, we might as well use index->tree_height to cache it.
7258 */
7260 {
7263 else
7265 }
7267 /*
7268 * Add a CPU-cost component to represent the costs of initial descent. We
7269 * just use log(N) here not log2(N) since the branching factor isn't
7270 * necessarily two anyway. As for btree, charge once per SA scan.
7271 */
7273 {
7277 }
7279 /*
7280 * Likewise add a per-page charge, calculated the same as for btrees.
7281 */
7291 }
7294 /*
7295 * Support routines for gincostestimate
7296 */
7299 {
7308 /*
7309 * Estimate the number of index terms that need to be searched for while
7310 * testing the given GIN query, and increment the counts in *counts
7311 * appropriately. If the query is unsatisfiable, return false.
7312 */
7313 static bool
7317 {
7318 FmgrInfo flinfo;
7319 Oid extractProcOid;
7320 Oid collation;
7322 Oid lefttype,
7323 righttype;
7329 int32 i;
7333 /*
7334 * Get the operator's strategy number and declared input data types within
7335 * the index opfamily. (We don't need the latter, but we use
7336 * get_op_opfamily_properties because it will throw error if it fails to
7337 * find a matching pg_amop entry.)
7338 */
7342 /*
7343 * GIN always uses the "default" support functions, which are those with
7344 * lefttype == righttype == the opclass' opcintype (see
7345 * IndexSupportInitialize in relcache.c).
7346 */
7350 GIN_EXTRACTQUERY_PROC);
7353 {
7354 /* should not happen; throw same error as index_getprocinfo */
7358 }
7360 /*
7361 * Choose collation to pass to extractProc (should match initGinState).
7362 */
7365 else
7373 collation,
7374 query,
7383 {
7384 /* No match is possible */
7386 }
7389 {
7390 /*
7391 * For partial match we haven't any information to estimate number of
7392 * matched entries in index, so, we just estimate it as 100
7393 */
7396 else
7400 }
7403 {
7405 }
7407 {
7408 /* Treat "include empty" like an exact-match item */
7412 }
7413 else
7414 {
7415 /* It's GIN_SEARCH_MODE_ALL */
7417 }
7420 }
7422 /*
7423 * Estimate the number of index terms that need to be searched for while
7424 * testing the given GIN index clause, and increment the counts in *counts
7425 * appropriately. If the query is unsatisfiable, return false.
7426 */
7427 static bool
7433 {
7437 /* aggressively reduce to a constant, and look through relabeling */
7443 /*
7444 * It's impossible to call extractQuery method for unknown operand. So
7445 * unless operand is a Const we can't do much; just assume there will be
7446 * one ordinary search entry from the operand at runtime.
7447 */
7449 {
7453 }
7455 /* If Const is null, there can be no matches */
7459 /* Otherwise, apply extractQuery and get the actual term counts */
7462 counts);
7463 }
7465 /*
7466 * Estimate the number of index terms that need to be searched for while
7467 * testing the given GIN index clause, and increment the counts in *counts
7468 * appropriately. If the query is unsatisfiable, return false.
7469 *
7470 * A ScalarArrayOpExpr will give rise to N separate indexscans at runtime,
7471 * each of which involves one value from the RHS array, plus all the
7472 * non-array quals (if any). To model this, we average the counts across
7473 * the RHS elements, and add the averages to the counts in *counts (which
7474 * correspond to per-indexscan costs). We also multiply counts->arrayScans
7475 * by N, causing gincostestimate to scale up its estimates accordingly.
7476 */
7477 static bool
7484 {
7488 int16 elmlen;
7494 GinQualCounts arraycounts;
7500 /* aggressively reduce to a constant, and look through relabeling */
7506 /*
7507 * It's impossible to call extractQuery method for unknown operand. So
7508 * unless operand is a Const we can't do much; just assume there will be
7509 * one ordinary search entry from each array entry at runtime, and fall
7510 * back on a probably-bad estimate of the number of array entries.
7511 */
7513 {
7518 }
7520 /* If Const is null, there can be no matches */
7524 /* Otherwise, extract the array elements and iterate over them */
7536 {
7537 GinQualCounts elemcounts;
7539 /* NULL can't match anything, so ignore, as the executor will */
7543 /* Otherwise, apply extractQuery and get the actual term counts */
7548 {
7549 /* We ignore array elements that are unsatisfiable patterns */
7550 numPossible++;
7554 {
7555 /*
7556 * Full index scan will be required. We treat this as if
7557 * every key in the index had been listed in the query; is
7558 * that reasonable?
7559 */
7563 }
7567 }
7568 }
7571 {
7572 /* No satisfiable patterns in the array */
7574 }
7576 /*
7577 * Now add the averages to the global counts. This will give us an
7578 * estimate of the average number of terms searched for in each indexscan,
7579 * including contributions from both array and non-array quals.
7580 */
7588 }
7590 /*
7591 * GIN has search behavior completely different from other index types
7592 */
7593 void
7598 {
7605 numDataPages,
7606 numPendingPages,
7607 numEntries;
7608 GinQualCounts counts;
7613 dataPagesFetched,
7614 dataPagesFetchedBySel;
7616 qual_arg_cost,
7617 spc_random_page_cost,
7618 outer_scans;
7619 Cost descentCost;
7620 Relation indexRel;
7621 GinStatsData ginStats;
7625 /*
7626 * Obtain statistical information from the meta page, if possible. Else
7627 * set ginStats to zeroes, and we'll cope below.
7628 */
7630 {
7631 /* Lock should have already been obtained in plancat.c */
7635 }
7636 else
7637 {
7639 }
7641 /*
7642 * Assuming we got valid (nonzero) stats at all, nPendingPages can be
7643 * trusted, but the other fields are data as of the last VACUUM. We can
7644 * scale them up to account for growth since then, but that method only
7645 * goes so far; in the worst case, the stats might be for a completely
7646 * empty index, and scaling them will produce pretty bogus numbers.
7647 * Somewhat arbitrarily, set the cutoff for doing scaling at 4X growth; if
7648 * it's grown more than that, fall back to estimating things only from the
7649 * assumed-accurate index size. But we'll trust nPendingPages in any case
7650 * so long as it's not clearly insane, ie, more than the index size.
7651 */
7654 else
7660 {
7661 /*
7662 * OK, the stats seem close enough to sane to be trusted. But we
7663 * still need to scale them by the ratio numPages / nTotalPages to
7664 * account for growth since the last VACUUM.
7665 */
7671 /* ensure we didn't round up too much */
7675 }
7676 else
7677 {
7678 /*
7679 * We might get here because it's a hypothetical index, or an index
7680 * created pre-9.1 and never vacuumed since upgrading (in which case
7681 * its stats would read as zeroes), or just because it's grown too
7682 * much since the last VACUUM for us to put our faith in scaling.
7683 *
7684 * Invent some plausible internal statistics based on the index page
7685 * count (and clamp that to at least 10 pages, just in case). We
7686 * estimate that 90% of the index is entry pages, and the rest is data
7687 * pages. Estimate 100 entries per entry page; this is rather bogus
7688 * since it'll depend on the size of the keys, but it's more robust
7689 * than trying to predict the number of entries per heap tuple.
7690 */
7695 }
7697 /* In an empty index, numEntries could be zero. Avoid divide-by-zero */
7701 /*
7702 * If the index is partial, AND the index predicate with the index-bound
7703 * quals to produce a more accurate idea of the number of rows covered by
7704 * the bound conditions.
7705 */
7708 /* Estimate the fraction of main-table tuples that will be visited */
7711 JOIN_INNER,
7712 NULL);
7714 /* fetch estimated page cost for tablespace containing index */
7717 NULL);
7719 /*
7720 * Generic assumption about index correlation: there isn't any.
7721 */
7724 /*
7725 * Examine quals to estimate number of search entries & partial matches
7726 */
7732 {
7737 {
7742 {
7744 index,
7750 }
7752 {
7754 index,
7757 numEntries,
7761 }
7762 else
7763 {
7764 /* shouldn't be anything else for a GIN index */
7767 }
7768 }
7769 }
7771 /* Fall out if there were any provably-unsatisfiable quals */
7773 {
7778 }
7780 /*
7781 * If attribute has a full scan and at the same time doesn't have normal
7782 * scan, then we'll have to scan all non-null entries of that attribute.
7783 * Currently, we don't have per-attribute statistics for GIN. Thus, we
7784 * must assume the whole GIN index has to be scanned in this case.
7785 */
7788 {
7790 {
7793 }
7794 }
7797 {
7798 /*
7799 * Full index scan will be required. We treat this as if every key in
7800 * the index had been listed in the query; is that reasonable?
7801 */
7805 }
7807 /* Will we have more than one iteration of a nestloop scan? */
7810 /*
7811 * Compute cost to begin scan, first of all, pay attention to pending
7812 * list.
7813 */
7816 /*
7817 * Estimate number of entry pages read. We need to do
7818 * counts.searchEntries searches. Use a power function as it should be,
7819 * but tuples on leaf pages usually is much greater. Here we include all
7820 * searches in entry tree, including search of first entry in partial
7821 * match algorithm
7822 */
7825 /*
7826 * Add an estimate of entry pages read by partial match algorithm. It's a
7827 * scan over leaf pages in entry tree. We haven't any useful stats here,
7828 * so estimate it as proportion. Because counts.partialEntries is really
7829 * pretty bogus (see code above), it's possible that it is more than
7830 * numEntries; clamp the proportion to ensure sanity.
7831 */
7837 /*
7838 * Partial match algorithm reads all data pages before doing actual scan,
7839 * so it's a startup cost. Again, we haven't any useful stats here, so
7840 * estimate it as proportion.
7841 */
7847 /*
7848 * Add a CPU-cost component to represent the costs of initial entry btree
7849 * descent. We don't charge any I/O cost for touching upper btree levels,
7850 * since they tend to stay in cache, but we still have to do about log2(N)
7851 * comparisons to descend a btree of N leaf tuples. We charge one
7852 * cpu_operator_cost per comparison.
7853 *
7854 * If there are ScalarArrayOpExprs, charge this once per SA scan. The
7855 * ones after the first one are not startup cost so far as the overall
7856 * plan is concerned, so add them only to "total" cost.
7857 */
7859 {
7863 }
7865 /*
7866 * Add a cpu cost per entry-page fetched. This is not amortized over a
7867 * loop.
7868 */
7870 *indexTotalCost += entryPagesFetched * counts.arrayScans * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
7872 /*
7873 * Add a cpu cost per data-page fetched. This is also not amortized over a
7874 * loop. Since those are the data pages from the partial match algorithm,
7875 * charge them as startup cost.
7876 */
7879 /*
7880 * Since we add the startup cost to the total cost later on, remove the
7881 * initial arrayscan from the total.
7882 */
7883 *indexTotalCost += dataPagesFetched * (counts.arrayScans - 1) * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
7885 /*
7886 * Calculate cache effects if more than one scan due to nestloops or array
7887 * quals. The result is pro-rated per nestloop scan, but the array qual
7888 * factor shouldn't be pro-rated (compare genericcostestimate).
7889 */
7891 {
7902 }
7904 /*
7905 * Here we use random page cost because logically-close pages could be far
7906 * apart on disk.
7907 */
7910 /*
7911 * Now compute the number of data pages fetched during the scan.
7912 *
7913 * We assume every entry to have the same number of items, and that there
7914 * is no overlap between them. (XXX: tsvector and array opclasses collect
7915 * statistics on the frequency of individual keys; it would be nice to use
7916 * those here.)
7917 */
7920 /*
7921 * If there is a lot of overlap among the entries, in particular if one of
7922 * the entries is very frequent, the above calculation can grossly
7923 * under-estimate. As a simple cross-check, calculate a lower bound based
7924 * on the overall selectivity of the quals. At a minimum, we must read
7925 * one item pointer for each matching entry.
7926 *
7927 * The width of each item pointer varies, based on the level of
7928 * compression. We don't have statistics on that, but an average of
7929 * around 3 bytes per item is fairly typical.
7930 */
7936 /* Add one page cpu-cost to the startup cost */
7939 /*
7940 * Add once again a CPU-cost for those data pages, before amortizing for
7941 * cache.
7942 */
7943 *indexTotalCost += dataPagesFetched * counts.arrayScans * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
7945 /* Account for cache effects, the same as above */
7947 {
7953 }
7955 /* And apply random_page_cost as the cost per page */
7959 /*
7960 * Add on index qual eval costs, much as in genericcostestimate. We charge
7961 * cpu but we can disregard indexorderbys, since GIN doesn't support
7962 * those.
7963 */
7970 /*
7971 * Add a cpu cost per search entry, corresponding to the actual visited
7972 * entries.
7973 */
7975 /* Now add a cpu cost per tuple in the posting lists / trees */
7978 }
7980 /*
7981 * BRIN has search behavior completely different from other index types
7982 */
7983 void
7988 {
7994 Cost spc_seq_page_cost;
7995 Cost spc_random_page_cost;
7998 BrinStatsData statsData;
8003 Relation indexRel;
8005 VariableStatData vardata;
8009 /* fetch estimated page cost for the tablespace containing the index */
8014 /*
8015 * Obtain some data from the index itself, if possible. Otherwise invent
8016 * some plausible internal statistics based on the relation page count.
8017 */
8019 {
8020 /*
8021 * A lock should have already been obtained on the index in plancat.c.
8022 */
8027 /* work out the actual number of ranges in the index */
8030 }
8031 else
8032 {
8033 /*
8034 * Assume default number of pages per range, and estimate the number
8035 * of ranges based on that.
8036 */
8042 }
8044 /*
8045 * Compute index correlation
8046 *
8047 * Because we can use all index quals equally when scanning, we can use
8048 * the largest correlation (in absolute value) among columns used by the
8049 * query. Start at zero, the worst possible case. If we cannot find any
8050 * correlation statistics, we will keep it as 0.
8051 */
8055 {
8059 /* attempt to lookup stats in relation for this index column */
8061 {
8062 /* Simple variable -- look to stats for the underlying table */
8065 {
8066 /*
8067 * The hook took control of acquiring a stats tuple. If it
8068 * did supply a tuple, it'd better have supplied a freefunc.
8069 */
8073 }
8074 else
8075 {
8082 }
8083 }
8084 else
8085 {
8086 /*
8087 * Looks like we've found an expression column in the index. Let's
8088 * see if there's any stats for it.
8089 */
8091 /* get the attnum from the 0-based index. */
8096 {
8097 /*
8098 * The hook took control of acquiring a stats tuple. If it
8099 * did supply a tuple, it'd better have supplied a freefunc.
8100 */
8104 }
8105 else
8106 {
8112 }
8113 }
8116 {
8117 AttStatsSlot sslot;
8121 ATTSTATSSLOT_NUMBERS))
8122 {
8132 }
8133 }
8136 }
8142 /*
8143 * Now calculate the minimum possible ranges we could match with if all of
8144 * the rows were in the perfect order in the table's heap.
8145 */
8148 /*
8149 * Now estimate the number of ranges that we'll touch by using the
8150 * indexCorrelation from the stats. Careful not to divide by zero (note
8151 * we're using the absolute value of the correlation).
8152 */
8155 else
8158 /* we expect to visit this portion of the table */
8165 /*
8166 * Compute the index qual costs, much as in genericcostestimate, to add to
8167 * the index costs. We can disregard indexorderbys, since BRIN doesn't
8168 * support those.
8169 */
8172 /*
8173 * Compute the startup cost as the cost to read the whole revmap
8174 * sequentially, including the cost to execute the index quals.
8175 */
8180 /*
8181 * To read a BRIN index there might be a bit of back and forth over
8182 * regular pages, as revmap might point to them out of sequential order;
8183 * calculate the total cost as reading the whole index in random order.
8184 */
8188 /*
8189 * Charge a small amount per range tuple which we expect to match to. This
8190 * is meant to reflect the costs of manipulating the bitmap. The BRIN scan
8191 * will set a bit for each page in the range when we find a matching
8192 * range, so we must multiply the charge by the number of pages in the
8193 * range.
8194 */
8199 }