| blob | f4b3e91baa89c8d78af9d22f241a5c759ea604a8 |
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)
3320 */
3323 {
3325 {
3326 /* Keep older item, forget new one */
3328 }
3329 else
3330 {
3331 /* Delete the older item */
3333 }
3334 }
3335 }
3345 }
3347 /*
3348 * estimate_num_groups - Estimate number of groups in a grouped query
3349 *
3350 * Given a query having a GROUP BY clause, estimate how many groups there
3351 * will be --- ie, the number of distinct combinations of the GROUP BY
3352 * expressions.
3353 *
3354 * This routine is also used to estimate the number of rows emitted by
3355 * a DISTINCT filtering step; that is an isomorphic problem. (Note:
3356 * actually, we only use it for DISTINCT when there's no grouping or
3357 * aggregation ahead of the DISTINCT.)
3358 *
3359 * Inputs:
3360 * root - the query
3361 * groupExprs - list of expressions being grouped by
3362 * input_rows - number of rows estimated to arrive at the group/unique
3363 * filter step
3364 * pgset - NULL, or a List** pointing to a grouping set to filter the
3365 * groupExprs against
3366 *
3367 * Outputs:
3368 * estinfo - When passed as non-NULL, the function will set bits in the
3369 * "flags" field in order to provide callers with additional information
3370 * about the estimation. Currently, we only set the SELFLAG_USED_DEFAULT
3371 * bit if we used any default values in the estimation.
3372 *
3373 * Given the lack of any cross-correlation statistics in the system, it's
3374 * impossible to do anything really trustworthy with GROUP BY conditions
3375 * involving multiple Vars. We should however avoid assuming the worst
3376 * case (all possible cross-product terms actually appear as groups) since
3377 * very often the grouped-by Vars are highly correlated. Our current approach
3378 * is as follows:
3379 * 1. Expressions yielding boolean are assumed to contribute two groups,
3380 * independently of their content, and are ignored in the subsequent
3381 * steps. This is mainly because tests like "col IS NULL" break the
3382 * heuristic used in step 2 especially badly.
3383 * 2. Reduce the given expressions to a list of unique Vars used. For
3384 * example, GROUP BY a, a + b is treated the same as GROUP BY a, b.
3385 * It is clearly correct not to count the same Var more than once.
3386 * It is also reasonable to treat f(x) the same as x: f() cannot
3387 * increase the number of distinct values (unless it is volatile,
3388 * which we consider unlikely for grouping), but it probably won't
3389 * reduce the number of distinct values much either.
3390 * As a special case, if a GROUP BY expression can be matched to an
3391 * expressional index for which we have statistics, then we treat the
3392 * whole expression as though it were just a Var.
3393 * 3. If the list contains Vars of different relations that are known equal
3394 * due to equivalence classes, then drop all but one of the Vars from each
3395 * known-equal set, keeping the one with smallest estimated # of values
3396 * (since the extra values of the others can't appear in joined rows).
3397 * Note the reason we only consider Vars of different relations is that
3398 * if we considered ones of the same rel, we'd be double-counting the
3399 * restriction selectivity of the equality in the next step.
3400 * 4. For Vars within a single source rel, we multiply together the numbers
3401 * of values, clamp to the number of rows in the rel (divided by 10 if
3402 * more than one Var), and then multiply by a factor based on the
3403 * selectivity of the restriction clauses for that rel. When there's
3404 * more than one Var, the initial product is probably too high (it's the
3405 * worst case) but clamping to a fraction of the rel's rows seems to be a
3406 * helpful heuristic for not letting the estimate get out of hand. (The
3407 * factor of 10 is derived from pre-Postgres-7.4 practice.) The factor
3408 * we multiply by to adjust for the restriction selectivity assumes that
3409 * the restriction clauses are independent of the grouping, which may not
3410 * be a valid assumption, but it's hard to do better.
3411 * 5. If there are Vars from multiple rels, we repeat step 4 for each such
3412 * rel, and multiply the results together.
3413 * Note that rels not containing grouped Vars are ignored completely, as are
3414 * join clauses. Such rels cannot increase the number of groups, and we
3415 * assume such clauses do not reduce the number either (somewhat bogus,
3416 * but we don't have the info to do better).
3417 */
3418 double
3421 {
3428 /* Zero the estinfo output parameter, if non-NULL */
3432 /*
3433 * We don't ever want to return an estimate of zero groups, as that tends
3434 * to lead to division-by-zero and other unpleasantness. The input_rows
3435 * estimate is usually already at least 1, but clamp it just in case it
3436 * isn't.
3437 */
3440 /*
3441 * If no grouping columns, there's exactly one group. (This can't happen
3442 * for normal cases with GROUP BY or DISTINCT, but it is possible for
3443 * corner cases with set operations.)
3444 */
3448 /*
3449 * Count groups derived from boolean grouping expressions. For other
3450 * expressions, find the unique Vars used, treating an expression as a Var
3451 * if we can find stats for it. For each one, record the statistical
3452 * estimate of number of distinct values (total in its table, without
3453 * regard for filtering).
3454 */
3459 {
3462 VariableStatData vardata;
3466 /* is expression in this grouping set? */
3470 /*
3471 * Set-returning functions in grouping columns are a bit problematic.
3472 * The code below will effectively ignore their SRF nature and come up
3473 * with a numdistinct estimate as though they were scalar functions.
3474 * We compensate by scaling up the end result by the largest SRF
3475 * rowcount estimate. (This will be an overestimate if the SRF
3476 * produces multiple copies of any output value, but it seems best to
3477 * assume the SRF's outputs are distinct. In any case, it's probably
3478 * pointless to worry too much about this without much better
3479 * estimates for SRF output rowcounts than we have today.)
3480 */
3485 /* Short-circuit for expressions returning boolean */
3487 {
3490 }
3492 /*
3493 * If examine_variable is able to deduce anything about the GROUP BY
3494 * expression, treat it as a single variable even if it's really more
3495 * complicated.
3496 *
3497 * XXX This has the consequence that if there's a statistics object on
3498 * the expression, we don't split it into individual Vars. This
3499 * affects our selection of statistics in
3500 * estimate_multivariate_ndistinct, because it's probably better to
3501 * use more accurate estimate for each expression and treat them as
3502 * independent, than to combine estimates for the extracted variables
3503 * when we don't know how that relates to the expressions.
3504 */
3507 {
3512 }
3515 /*
3516 * Else pull out the component Vars. Handle PlaceHolderVars by
3517 * recursing into their arguments (effectively assuming that the
3518 * PlaceHolderVar doesn't change the number of groups, which boils
3519 * down to ignoring the possible addition of nulls to the result set).
3520 */
3522 PVC_RECURSE_AGGREGATES |
3523 PVC_RECURSE_WINDOWFUNCS |
3524 PVC_RECURSE_PLACEHOLDERS);
3526 /*
3527 * If we find any variable-free GROUP BY item, then either it is a
3528 * constant (and we can ignore it) or it contains a volatile function;
3529 * in the latter case we punt and assume that each input row will
3530 * yield a distinct group.
3531 */
3533 {
3537 }
3539 /*
3540 * Else add variables to varinfos list
3541 */
3543 {
3549 }
3550 }
3552 /*
3553 * If now no Vars, we must have an all-constant or all-boolean GROUP BY
3554 * list.
3555 */
3557 {
3558 /* Apply SRF multiplier as we would do in the long path */
3560 /* Round off */
3562 /* Guard against out-of-range answers */
3568 }
3570 /*
3571 * Group Vars by relation and estimate total numdistinct.
3572 *
3573 * For each iteration of the outer loop, we process the frontmost Var in
3574 * varinfos, plus all other Vars in the same relation. We remove these
3575 * Vars from the newvarinfos list for the next iteration. This is the
3576 * easiest way to group Vars of same rel together.
3577 */
3578 do
3579 {
3588 /*
3589 * Split the list of varinfos in two - one for the current rel, one
3590 * for remaining Vars on other rels.
3591 */
3594 {
3598 {
3599 /* varinfos on current rel */
3601 }
3602 else
3603 {
3604 /* not time to process varinfo2 yet */
3606 }
3607 }
3609 /*
3610 * Get the numdistinct estimate for the Vars of this rel. We
3611 * iteratively search for multivariate n-distinct with maximum number
3612 * of vars; assuming that each var group is independent of the others,
3613 * we multiply them together. Any remaining relvarinfos after no more
3614 * multivariate matches are found are assumed independent too, so
3615 * their individual ndistinct estimates are multiplied also.
3616 *
3617 * While iterating, count how many separate numdistinct values we
3618 * apply. We apply a fudge factor below, but only if we multiplied
3619 * more than one such values.
3620 */
3622 {
3627 {
3631 relvarcount++;
3632 }
3633 else
3634 {
3636 {
3642 relvarcount++;
3644 /*
3645 * When varinfo2's isdefault is set then we'd better set
3646 * the SELFLAG_USED_DEFAULT bit in the EstimationInfo.
3647 */
3650 }
3652 /* we're done with this relation */
3654 }
3655 }
3657 /*
3658 * Sanity check --- don't divide by zero if empty relation.
3659 */
3662 {
3663 /*
3664 * Clamp to size of rel, or size of rel / 10 if multiple Vars. The
3665 * fudge factor is because the Vars are probably correlated but we
3666 * don't know by how much. We should never clamp to less than the
3667 * largest ndistinct value for any of the Vars, though, since
3668 * there will surely be at least that many groups.
3669 */
3673 {
3676 {
3678 /* for sanity in case some ndistinct is too large: */
3681 }
3682 }
3686 /*
3687 * Update the estimate based on the restriction selectivity,
3688 * guarding against division by zero when reldistinct is zero.
3689 * Also skip this if we know that we are returning all rows.
3690 */
3692 {
3693 /*
3694 * Given a table containing N rows with n distinct values in a
3695 * uniform distribution, if we select p rows at random then
3696 * the expected number of distinct values selected is
3697 *
3698 * n * (1 - product((N-N/n-i)/(N-i), i=0..p-1))
3699 *
3700 * = n * (1 - (N-N/n)! / (N-N/n-p)! * (N-p)! / N!)
3701 *
3702 * See "Approximating block accesses in database
3703 * organizations", S. B. Yao, Communications of the ACM,
3704 * Volume 20 Issue 4, April 1977 Pages 260-261.
3705 *
3706 * Alternatively, re-arranging the terms from the factorials,
3707 * this may be written as
3708 *
3709 * n * (1 - product((N-p-i)/(N-i), i=0..N/n-1))
3710 *
3711 * This form of the formula is more efficient to compute in
3712 * the common case where p is larger than N/n. Additionally,
3713 * as pointed out by Dell'Era, if i << N for all terms in the
3714 * product, it can be approximated by
3715 *
3716 * n * (1 - ((N-p)/N)^(N/n))
3717 *
3718 * See "Expected distinct values when selecting from a bag
3719 * without replacement", Alberto Dell'Era,
3720 * http://www.adellera.it/investigations/distinct_balls/.
3721 *
3722 * The condition i << N is equivalent to n >> 1, so this is a
3723 * good approximation when the number of distinct values in
3724 * the table is large. It turns out that this formula also
3725 * works well even when n is small.
3726 */
3727 reldistinct *=
3730 }
3733 /*
3734 * Update estimate of total distinct groups.
3735 */
3737 }
3742 /* Now we can account for the effects of any SRFs */
3745 /* Round off */
3748 /* Guard against out-of-range answers */
3755 }
3757 /*
3758 * Estimate hash bucket statistics when the specified expression is used
3759 * as a hash key for the given number of buckets.
3760 *
3761 * This attempts to determine two values:
3762 *
3763 * 1. The frequency of the most common value of the expression (returns
3764 * zero into *mcv_freq if we can't get that).
3765 *
3766 * 2. The "bucketsize fraction", ie, average number of entries in a bucket
3767 * divided by total tuples in relation.
3768 *
3769 * XXX This is really pretty bogus since we're effectively assuming that the
3770 * distribution of hash keys will be the same after applying restriction
3771 * clauses as it was in the underlying relation. However, we are not nearly
3772 * smart enough to figure out how the restrict clauses might change the
3773 * distribution, so this will have to do for now.
3774 *
3775 * We are passed the number of buckets the executor will use for the given
3776 * input relation. If the data were perfectly distributed, with the same
3777 * number of tuples going into each available bucket, then the bucketsize
3778 * fraction would be 1/nbuckets. But this happy state of affairs will occur
3779 * only if (a) there are at least nbuckets distinct data values, and (b)
3780 * we have a not-too-skewed data distribution. Otherwise the buckets will
3781 * be nonuniformly occupied. If the other relation in the join has a key
3782 * distribution similar to this one's, then the most-loaded buckets are
3783 * exactly those that will be probed most often. Therefore, the "average"
3784 * bucket size for costing purposes should really be taken as something close
3785 * to the "worst case" bucket size. We try to estimate this by adjusting the
3786 * fraction if there are too few distinct data values, and then scaling up
3787 * by the ratio of the most common value's frequency to the average frequency.
3788 *
3789 * If no statistics are available, use a default estimate of 0.1. This will
3790 * discourage use of a hash rather strongly if the inner relation is large,
3791 * which is what we want. We do not want to hash unless we know that the
3792 * inner rel is well-dispersed (or the alternatives seem much worse).
3793 *
3794 * The caller should also check that the mcv_freq is not so large that the
3795 * most common value would by itself require an impractically large bucket.
3796 * In a hash join, the executor can split buckets if they get too big, but
3797 * obviously that doesn't help for a bucket that contains many duplicates of
3798 * the same value.
3799 */
3800 void
3804 {
3805 VariableStatData vardata;
3807 ndistinct,
3808 stanullfrac,
3809 avgfreq;
3811 AttStatsSlot sslot;
3815 /* Look up the frequency of the most common value, if available */
3819 {
3822 ATTSTATSSLOT_NUMBERS))
3823 {
3824 /*
3825 * The first MCV stat is for the most common value.
3826 */
3830 }
3831 }
3833 /* Get number of distinct values */
3836 /*
3837 * If ndistinct isn't real, punt. We normally return 0.1, but if the
3838 * mcv_freq is known to be even higher than that, use it instead.
3839 */
3841 {
3845 }
3847 /* Get fraction that are null */
3849 {
3850 Form_pg_statistic stats;
3854 }
3855 else
3858 /* Compute avg freq of all distinct data values in raw relation */
3861 /*
3862 * Adjust ndistinct to account for restriction clauses. Observe we are
3863 * assuming that the data distribution is affected uniformly by the
3864 * restriction clauses!
3865 *
3866 * XXX Possibly better way, but much more expensive: multiply by
3867 * selectivity of rel's restriction clauses that mention the target Var.
3868 */
3870 {
3873 }
3875 /*
3876 * Initial estimate of bucketsize fraction is 1/nbuckets as long as the
3877 * number of buckets is less than the expected number of distinct values;
3878 * otherwise it is 1/ndistinct.
3879 */
3882 else
3885 /*
3886 * Adjust estimated bucketsize upward to account for skewed distribution.
3887 */
3891 /*
3892 * Clamp bucketsize to sane range (the above adjustment could easily
3893 * produce an out-of-range result). We set the lower bound a little above
3894 * zero, since zero isn't a very sane result.
3895 */
3904 }
3906 /*
3907 * estimate_hashagg_tablesize
3908 * estimate the number of bytes that a hash aggregate hashtable will
3909 * require based on the agg_costs, path width and number of groups.
3910 *
3911 * We return the result as "double" to forestall any possible overflow
3912 * problem in the multiplication by dNumGroups.
3913 *
3914 * XXX this may be over-estimating the size now that hashagg knows to omit
3915 * unneeded columns from the hashtable. Also for mixed-mode grouping sets,
3916 * grouping columns not in the hashed set are counted here even though hashagg
3917 * won't store them. Is this a problem?
3918 */
3919 double
3922 {
3923 Size hashentrysize;
3929 /*
3930 * Note that this disregards the effect of fill-factor and growth policy
3931 * of the hash table. That's probably ok, given that the default
3932 * fill-factor is relatively high. It'd be hard to meaningfully factor in
3933 * "double-in-size" growth policies here.
3934 */
3936 }
3939 /*-------------------------------------------------------------------------
3940 *
3941 * Support routines
3942 *
3943 *-------------------------------------------------------------------------
3944 */
3946 /*
3947 * Find applicable ndistinct statistics for the given list of VarInfos (which
3948 * must all belong to the given rel), and update *ndistinct to the estimate of
3949 * the MVNDistinctItem that best matches. If a match it found, *varinfos is
3950 * updated to remove the list of matched varinfos.
3951 *
3952 * Varinfos that aren't for simple Vars are ignored.
3953 *
3954 * Return true if we're able to find a match, false otherwise.
3955 */
3956 static bool
3959 {
3968 /* bail out immediately if the table has no extended statistics */
3972 /* look for the ndistinct statistics object matching the most vars */
3976 {
3982 /* skip statistics of other kinds */
3986 /* skip statistics with mismatching stxdinherit value */
3990 /*
3991 * Determine how many expressions (and variables in non-matched
3992 * expressions) match. We'll then use these numbers to pick the
3993 * statistics object that best matches the clauses.
3994 */
3996 {
3999 AttrNumber attnum;
4003 /* simple Var, search in statistics keys directly */
4005 {
4008 /*
4009 * Ignore system attributes - we don't support statistics on
4010 * them, so can't match them (and it'd fail as the values are
4011 * negative).
4012 */
4017 nshared_vars++;
4020 }
4022 /* expression - see if it's in the statistics object */
4024 {
4028 {
4029 nshared_exprs++;
4031 }
4032 }
4033 }
4038 /*
4039 * Does this statistics object match more columns than the currently
4040 * best object? If so, use this one instead.
4041 *
4042 * XXX This should break ties using name of the object, or something
4043 * like that, to make the outcome stable.
4044 */
4047 {
4052 }
4053 }
4055 /* No match? */
4063 /*
4064 * If we have a match, search it for the specific item that matches (there
4065 * must be one), and construct the output values.
4066 */
4068 {
4074 AttrNumber attnum_offset;
4076 /*
4077 * How much we need to offset the attnums? If there are no
4078 * expressions, no offset is needed. Otherwise offset enough to move
4079 * the lowest one (which is equal to number of expressions) to 1.
4080 */
4083 else
4086 /* see what actually matched */
4088 {
4095 /*
4096 * Process a simple Var expression, by matching it to keys
4097 * directly. If there's a matching expression, we'll try matching
4098 * it later.
4099 */
4101 {
4104 /*
4105 * Ignore expressions on system attributes. Can't rely on the
4106 * bms check for negative values.
4107 */
4111 /* Is the variable covered by the statistics object? */
4117 /* ensure sufficient offset */
4123 }
4125 /*
4126 * XXX Maybe we should allow searching the expressions even if we
4127 * found an attribute matching the expression? That would handle
4128 * trivial expressions like "(a)" but it seems fairly useless.
4129 */
4133 /* expression - see if it's in the statistics object */
4136 {
4140 {
4145 /* ensure sufficient offset */
4150 /* there should be just one matching expression */
4152 }
4154 idx++;
4155 }
4156 }
4158 /* Find the specific item that exactly matches the combination */
4160 {
4167 /* assume it's the right item */
4170 /* check that all item attributes/expressions fit the match */
4172 {
4175 /*
4176 * Thanks to how we constructed the matched bitmap above, we
4177 * can just offset all attnums the same way.
4178 */
4182 {
4183 /* nah, it's not this item */
4186 }
4187 }
4189 /*
4190 * If the item has all the matched attributes, we know it's the
4191 * right one - there can't be a better one. matching more.
4192 */
4195 }
4197 /*
4198 * Make sure we found an item. There has to be one, because ndistinct
4199 * statistics includes all combinations of attributes.
4200 */
4204 /* Form the output varinfo list, keeping only unmatched ones */
4206 {
4211 /*
4212 * Let's look at plain variables first, because it's the most
4213 * common case and the check is quite cheap. We can simply get the
4214 * attnum and check (with an offset) matched bitmap.
4215 */
4217 {
4220 /*
4221 * If it's a system attribute, we're done. We don't support
4222 * extended statistics on system attributes, so it's clearly
4223 * not matched. Just keep the expression and continue.
4224 */
4226 {
4229 }
4231 /* apply the same offset as above */
4234 /* if it's not matched, keep the varinfo */
4238 /* The rest of the loop deals with complex expressions. */
4240 }
4242 /*
4243 * Process complex expressions, not just simple Vars.
4244 *
4245 * First, we search for an exact match of an expression. If we
4246 * find one, we can just discard the whole GroupVarInfo, with all
4247 * the variables we extracted from it.
4248 *
4249 * Otherwise we inspect the individual vars, and try matching it
4250 * to variables in the item.
4251 */
4253 {
4257 {
4260 }
4261 }
4263 /* found exact match, skip */
4268 }
4273 }
4276 }
4278 /*
4279 * convert_to_scalar
4280 * Convert non-NULL values of the indicated types to the comparison
4281 * scale needed by scalarineqsel().
4282 * Returns "true" if successful.
4283 *
4284 * XXX this routine is a hack: ideally we should look up the conversion
4285 * subroutines in pg_type.
4286 *
4287 * All numeric datatypes are simply converted to their equivalent
4288 * "double" values. (NUMERIC values that are outside the range of "double"
4289 * are clamped to +/- HUGE_VAL.)
4290 *
4291 * String datatypes are converted by convert_string_to_scalar(),
4292 * which is explained below. The reason why this routine deals with
4293 * three values at a time, not just one, is that we need it for strings.
4294 *
4295 * The bytea datatype is just enough different from strings that it has
4296 * to be treated separately.
4297 *
4298 * The several datatypes representing absolute times are all converted
4299 * to Timestamp, which is actually an int64, and then we promote that to
4300 * a double. Note this will give correct results even for the "special"
4301 * values of Timestamp, since those are chosen to compare correctly;
4302 * see timestamp_cmp.
4303 *
4304 * The several datatypes representing relative times (intervals) are all
4305 * converted to measurements expressed in seconds.
4306 */
4307 static bool
4311 {
4314 /*
4315 * Both the valuetypid and the boundstypid should exactly match the
4316 * declared input type(s) of the operator we are invoked for. However,
4317 * extensions might try to use scalarineqsel as estimator for operators
4318 * with input type(s) we don't handle here; in such cases, we want to
4319 * return false, not fail. In any case, we mustn't assume that valuetypid
4320 * and boundstypid are identical.
4321 *
4322 * XXX The histogram we are interpolating between points of could belong
4323 * to a column that's only binary-compatible with the declared type. In
4324 * essence we are assuming that the semantics of binary-compatible types
4325 * are enough alike that we can use a histogram generated with one type's
4326 * operators to estimate selectivity for the other's. This is outright
4327 * wrong in some cases --- in particular signed versus unsigned
4328 * interpretation could trip us up. But it's useful enough in the
4329 * majority of cases that we do it anyway. Should think about more
4330 * rigorous ways to do it.
4331 */
4333 {
4334 /*
4335 * Built-in numeric types
4336 */
4364 /*
4365 * Built-in string types
4366 */
4372 {
4380 /*
4381 * Bail out if any of the values is not of string type. We
4382 * might leak converted strings for the other value(s), but
4383 * that's not worth troubling over.
4384 */
4395 }
4397 /*
4398 * Built-in bytea type
4399 */
4401 {
4402 /* We only support bytea vs bytea comparison */
4409 }
4411 /*
4412 * Built-in time types
4413 */
4428 /*
4429 * Built-in network types
4430 */
4442 }
4443 /* Don't know how to convert */
4446 }
4448 /*
4449 * Do convert_to_scalar()'s work for any numeric data type.
4450 *
4451 * On failure (e.g., unsupported typid), set *failure to true;
4452 * otherwise, that variable is not changed.
4453 */
4454 static double
4456 {
4458 {
4472 /* Note: out-of-range values will be clamped to +-HUGE_VAL */
4475 value));
4488 /* we can treat OIDs as integers... */
4490 }
4494 }
4496 /*
4497 * Do convert_to_scalar()'s work for any character-string data type.
4498 *
4499 * String datatypes are converted to a scale that ranges from 0 to 1,
4500 * where we visualize the bytes of the string as fractional digits.
4501 *
4502 * We do not want the base to be 256, however, since that tends to
4503 * generate inflated selectivity estimates; few databases will have
4504 * occurrences of all 256 possible byte values at each position.
4505 * Instead, use the smallest and largest byte values seen in the bounds
4506 * as the estimated range for each byte, after some fudging to deal with
4507 * the fact that we probably aren't going to see the full range that way.
4508 *
4509 * An additional refinement is that we discard any common prefix of the
4510 * three strings before computing the scaled values. This allows us to
4511 * "zoom in" when we encounter a narrow data range. An example is a phone
4512 * number database where all the values begin with the same area code.
4513 * (Actually, the bounds will be adjacent histogram-bin-boundary values,
4514 * so this is more likely to happen than you might think.)
4515 */
4516 static void
4523 {
4525 rangehi;
4530 {
4535 }
4537 {
4542 }
4543 /* If range includes any upper-case ASCII chars, make it include all */
4545 {
4550 }
4551 /* Ditto lower-case */
4553 {
4558 }
4559 /* Ditto digits */
4561 {
4566 }
4568 /*
4569 * If range includes less than 10 chars, assume we have not got enough
4570 * data, and make it include regular ASCII set.
4571 */
4573 {
4576 }
4578 /*
4579 * Now strip any common prefix of the three strings.
4580 */
4582 {
4586 }
4588 /*
4589 * Now we can do the conversions.
4590 */
4594 }
4596 static double
4598 {
4601 denom,
4602 base;
4607 /*
4608 * There seems little point in considering more than a dozen bytes from
4609 * the string. Since base is at least 10, that will give us nominal
4610 * resolution of at least 12 decimal digits, which is surely far more
4611 * precision than this estimation technique has got anyway (especially in
4612 * non-C locales). Also, even with the maximum possible base of 256, this
4613 * ensures denom cannot grow larger than 256^13 = 2.03e31, which will not
4614 * overflow on any known machine.
4615 */
4619 /* Convert initial characters to fraction */
4624 {
4633 }
4636 }
4638 /*
4639 * Convert a string-type Datum into a palloc'd, null-terminated string.
4640 *
4641 * On failure (e.g., unsupported typid), set *failure to true;
4642 * otherwise, that variable is not changed. (We'll return NULL on failure.)
4643 *
4644 * When using a non-C locale, we must pass the string through strxfrm()
4645 * before continuing, so as to generate correct locale-specific results.
4646 */
4649 {
4653 {
4665 {
4670 }
4674 }
4677 {
4682 /*
4683 * XXX: We could guess at a suitable output buffer size and only call
4684 * strxfrm twice if our guess is too small.
4685 *
4686 * XXX: strxfrm doesn't support UTF-8 encoding on Win32, it can return
4687 * bogus data or set an error. This is not really a problem unless it
4688 * crashes since it will only give an estimation error and nothing
4689 * fatal.
4690 */
4692 #ifdef WIN32
4694 /*
4695 * On Windows, strxfrm returns INT_MAX when an error occurs. Instead
4696 * of trying to allocate this much memory (and fail), just return the
4697 * original string unmodified as if we were in the C locale.
4698 */
4701 #endif
4705 /*
4706 * Some systems (e.g., glibc) can return a smaller value from the
4707 * second call than the first; thus the Assert must be <= not ==.
4708 */
4712 }
4715 }
4717 /*
4718 * Do convert_to_scalar()'s work for any bytea data type.
4719 *
4720 * Very similar to convert_string_to_scalar except we can't assume
4721 * null-termination and therefore pass explicit lengths around.
4722 *
4723 * Also, assumptions about likely "normal" ranges of characters have been
4724 * removed - a data range of 0..255 is always used, for now. (Perhaps
4725 * someday we will add information about actual byte data range to
4726 * pg_statistic.)
4727 */
4728 static void
4731 Datum lobound,
4733 Datum hibound,
4735 {
4740 rangehi,
4744 i,
4745 minlen;
4750 /*
4751 * Assume bytea data is uniformly distributed across all byte values.
4752 */
4756 /*
4757 * Now strip any common prefix of the three strings.
4758 */
4761 {
4766 }
4768 /*
4769 * Now we can do the conversions.
4770 */
4774 }
4776 static double
4779 {
4781 denom,
4782 base;
4787 /*
4788 * Since base is 256, need not consider more than about 10 chars (even
4789 * this many seems like overkill)
4790 */
4794 /* Convert initial characters to fraction */
4799 {
4808 }
4811 }
4813 /*
4814 * Do convert_to_scalar()'s work for any timevalue data type.
4815 *
4816 * On failure (e.g., unsupported typid), set *failure to true;
4817 * otherwise, that variable is not changed.
4818 */
4819 static double
4821 {
4823 {
4831 {
4834 /*
4835 * Convert the month part of Interval to days using assumed
4836 * average month length of 365.25/12.0 days. Not too
4837 * accurate, but plenty good enough for our purposes.
4838 *
4839 * This also works for infinite intervals, which just have all
4840 * fields set to INT_MIN/INT_MAX, and so will produce a result
4841 * smaller/larger than any finite interval.
4842 */
4845 }
4849 {
4852 /* use GMT-equivalent time */
4854 }
4855 }
4859 }
4862 /*
4863 * get_restriction_variable
4864 * Examine the args of a restriction clause to see if it's of the
4865 * form (variable op pseudoconstant) or (pseudoconstant op variable),
4866 * where "variable" could be either a Var or an expression in vars of a
4867 * single relation. If so, extract information about the variable,
4868 * and also indicate which side it was on and the other argument.
4869 *
4870 * Inputs:
4871 * root: the planner info
4872 * args: clause argument list
4873 * varRelid: see specs for restriction selectivity functions
4874 *
4875 * Outputs: (these are valid only if true is returned)
4876 * *vardata: gets information about variable (see examine_variable)
4877 * *other: gets other clause argument, aggressively reduced to a constant
4878 * *varonleft: set true if variable is on the left, false if on the right
4879 *
4880 * Returns true if a variable is identified, otherwise false.
4881 *
4882 * Note: if there are Vars on both sides of the clause, we must fail, because
4883 * callers are expecting that the other side will act like a pseudoconstant.
4884 */
4885 bool
4889 {
4892 VariableStatData rdata;
4894 /* Fail if not a binary opclause (probably shouldn't happen) */
4901 /*
4902 * Examine both sides. Note that when varRelid is nonzero, Vars of other
4903 * relations will be treated as pseudoconstants.
4904 */
4908 /*
4909 * If one side is a variable and the other not, we win.
4910 */
4912 {
4915 /* Assume we need no ReleaseVariableStats(rdata) here */
4917 }
4920 {
4923 /* Assume we need no ReleaseVariableStats(*vardata) here */
4926 }
4928 /* Oops, clause has wrong structure (probably var op var) */
4933 }
4935 /*
4936 * get_join_variables
4937 * Apply examine_variable() to each side of a join clause.
4938 * Also, attempt to identify whether the join clause has the same
4939 * or reversed sense compared to the SpecialJoinInfo.
4940 *
4941 * We consider the join clause "normal" if it is "lhs_var OP rhs_var",
4942 * or "reversed" if it is "rhs_var OP lhs_var". In complicated cases
4943 * where we can't tell for sure, we default to assuming it's normal.
4944 */
4945 void
4949 {
4968 else
4970 }
4972 /* statext_expressions_load copies the tuple, so just pfree it. */
4973 static void
4975 {
4977 }
4979 /*
4980 * examine_variable
4981 * Try to look up statistical data about an expression.
4982 * Fill in a VariableStatData struct to describe the expression.
4983 *
4984 * Inputs:
4985 * root: the planner info
4986 * node: the expression tree to examine
4987 * varRelid: see specs for restriction selectivity functions
4988 *
4989 * Outputs: *vardata is filled as follows:
4990 * var: the input expression (with any binary relabeling stripped, if
4991 * it is or contains a variable; but otherwise the type is preserved)
4992 * rel: RelOptInfo for relation containing variable; NULL if expression
4993 * contains no Vars (NOTE this could point to a RelOptInfo of a
4994 * subquery, not one in the current query).
4995 * statsTuple: the pg_statistic entry for the variable, if one exists;
4996 * otherwise NULL.
4997 * freefunc: pointer to a function to release statsTuple with.
4998 * vartype: exposed type of the expression; this should always match
4999 * the declared input type of the operator we are estimating for.
5000 * atttype, atttypmod: actual type/typmod of the "var" expression. This is
5001 * commonly the same as the exposed type of the variable argument,
5002 * but can be different in binary-compatible-type cases.
5003 * isunique: true if we were able to match the var to a unique index or a
5004 * single-column DISTINCT clause, implying its values are unique for
5005 * this query. (Caution: this should be trusted for statistical
5006 * purposes only, since we do not check indimmediate nor verify that
5007 * the exact same definition of equality applies.)
5008 * acl_ok: true if current user has permission to read the column(s)
5009 * underlying the pg_statistic entry. This is consulted by
5010 * statistic_proc_security_check().
5011 *
5012 * Caller is responsible for doing ReleaseVariableStats() before exiting.
5013 */
5014 void
5017 {
5019 Relids varnos;
5022 /* Make sure we don't return dangling pointers in vardata */
5025 /* Save the exposed type of the expression */
5028 /* Look inside any binary-compatible relabeling */
5032 else
5035 /* Fast path for a simple Var */
5039 {
5042 /* Set up result fields other than the stats tuple */
5049 /* Try to locate some stats */
5053 }
5055 /*
5056 * Okay, it's a more complicated expression. Determine variable
5057 * membership. Note that when varRelid isn't zero, only vars of that
5058 * relation are considered "real" vars.
5059 */
5065 {
5066 /* No Vars at all ... must be pseudo-constant clause */
5067 }
5068 else
5069 {
5073 {
5075 {
5079 }
5080 /* else treat it as a constant */
5081 }
5082 else
5083 {
5084 /* varnos has multiple relids */
5086 {
5087 /* treat it as a variable of a join relation */
5090 }
5092 {
5093 /* ignore the vars belonging to other relations */
5096 /* note: no point in expressional-index search here */
5097 }
5098 /* else treat it as a constant */
5099 }
5100 }
5109 {
5110 /*
5111 * We have an expression in vars of a single relation. Try to match
5112 * it to expressional index columns, in hopes of finding some
5113 * statistics.
5114 *
5115 * Note that we consider all index columns including INCLUDE columns,
5116 * since there could be stats for such columns. But the test for
5117 * uniqueness needs to be warier.
5118 *
5119 * XXX it's conceivable that there are multiple matches with different
5120 * index opfamilies; if so, we need to pick one that matches the
5121 * operator we are estimating for. FIXME later.
5122 */
5125 Oid userid;
5127 /*
5128 * Determine the user ID to use for privilege checks: either
5129 * onerel->userid if it's set (e.g., in case we're accessing the table
5130 * via a view), or the current user otherwise.
5131 *
5132 * If we drill down to child relations, we keep using the same userid:
5133 * it's going to be the same anyway, due to how we set up the relation
5134 * tree (q.v. build_simple_rel).
5135 */
5139 {
5149 {
5151 {
5160 {
5161 /*
5162 * Found a match ... is it a unique index? Tests here
5163 * should match has_unique_index().
5164 */
5171 /*
5172 * Has it got stats? We only consider stats for
5173 * non-partial indexes, since partial indexes probably
5174 * don't reflect whole-relation statistics; the above
5175 * check for uniqueness is the only info we take from
5176 * a partial index.
5177 *
5178 * An index stats hook, however, must make its own
5179 * decisions about what to do with partial indexes.
5180 */
5184 {
5185 /*
5186 * The hook took control of acquiring a stats
5187 * tuple. If it did supply a tuple, it'd better
5188 * have supplied a freefunc.
5189 */
5193 }
5195 {
5204 {
5205 /* Get index's table for permission check */
5211 /*
5212 * For simplicity, we insist on the whole
5213 * table being selectable, rather than trying
5214 * to identify which column(s) the index
5215 * depends on. Also require all rows to be
5216 * selectable --- there must be no
5217 * securityQuals from security barrier views
5218 * or RLS policies.
5219 */
5225 /*
5226 * If the user doesn't have permissions to
5227 * access an inheritance child relation, check
5228 * the permissions of the table actually
5229 * mentioned in the query, since most likely
5230 * the user does have that permission. Note
5231 * that whole-table select privilege on the
5232 * parent doesn't quite guarantee that the
5233 * user could read all columns of the child.
5234 * But in practice it's unlikely that any
5235 * interesting security violation could result
5236 * from allowing access to the expression
5237 * index's stats, so we allow it anyway. See
5238 * similar code in examine_simple_variable()
5239 * for additional comments.
5240 */
5243 {
5251 {
5254 }
5256 {
5257 /* Repeat access check on this rel */
5264 userid,
5266 }
5267 }
5268 }
5269 else
5270 {
5271 /* suppress leakproofness checks later */
5273 }
5274 }
5277 }
5279 }
5280 }
5283 }
5285 /*
5286 * Search extended statistics for one with a matching expression.
5287 * There might be multiple ones, so just grab the first one. In the
5288 * future, we might consider the statistics target (and pick the most
5289 * accurate statistics) and maybe some other parameters.
5290 */
5292 {
5298 /*
5299 * Stop once we've found statistics for the expression (either
5300 * from extended stats, or for an index in the preceding loop).
5301 */
5305 /* skip stats without per-expression stats */
5309 /* skip stats with mismatching stxdinherit value */
5315 {
5320 /* strip RelabelType before comparing it */
5324 /* found a match, see if we can extract pg_statistic row */
5326 {
5327 /*
5328 * XXX Not sure if we should cache the tuple somewhere.
5329 * Now we just create a new copy every time.
5330 */
5336 /*
5337 * For simplicity, we insist on the whole table being
5338 * selectable, rather than trying to identify which
5339 * column(s) the statistics object depends on. Also
5340 * require all rows to be selectable --- there must be no
5341 * securityQuals from security barrier views or RLS
5342 * policies.
5343 */
5349 /*
5350 * If the user doesn't have permissions to access an
5351 * inheritance child relation, check the permissions of
5352 * the table actually mentioned in the query, since most
5353 * likely the user does have that permission. Note that
5354 * whole-table select privilege on the parent doesn't
5355 * quite guarantee that the user could read all columns of
5356 * the child. But in practice it's unlikely that any
5357 * interesting security violation could result from
5358 * allowing access to the expression stats, so we allow it
5359 * anyway. See similar code in examine_simple_variable()
5360 * for additional comments.
5361 */
5364 {
5372 {
5375 }
5377 {
5378 /* Repeat access check on this rel */
5385 userid,
5387 }
5388 }
5391 }
5393 pos++;
5394 }
5395 }
5396 }
5397 }
5399 /*
5400 * examine_simple_variable
5401 * Handle a simple Var for examine_variable
5402 *
5403 * This is split out as a subroutine so that we can recurse to deal with
5404 * Vars referencing subqueries (either sub-SELECT-in-FROM or CTE style).
5405 *
5406 * We already filled in all the fields of *vardata except for the stats tuple.
5407 */
5408 static void
5411 {
5418 {
5419 /*
5420 * The hook took control of acquiring a stats tuple. If it did supply
5421 * a tuple, it'd better have supplied a freefunc.
5422 */
5426 }
5428 {
5429 /*
5430 * Plain table or parent of an inheritance appendrel, so look up the
5431 * column in pg_statistic
5432 */
5440 {
5442 Oid userid;
5444 /*
5445 * Check if user has permission to read this column. We require
5446 * all rows to be accessible, so there must be no securityQuals
5447 * from security barrier views or RLS policies.
5448 *
5449 * Normally the Var will have an associated RelOptInfo from which
5450 * we can find out which userid to do the check as; but it might
5451 * not if it's a RETURNING Var for an INSERT target relation. In
5452 * that case use the RTEPermissionInfo associated with the RTE.
5453 */
5456 else
5457 {
5462 }
5473 /*
5474 * If the user doesn't have permissions to access an inheritance
5475 * child relation or specifically this attribute, check the
5476 * permissions of the table/column actually mentioned in the
5477 * query, since most likely the user does have that permission
5478 * (else the query will fail at runtime), and if the user can read
5479 * the column there then he can get the values of the child table
5480 * too. To do that, we must find out which of the root parent's
5481 * attributes the child relation's attribute corresponds to.
5482 */
5485 {
5493 /*
5494 * Partitions are mapped to their immediate parent, not the
5495 * root parent, so must be ready to walk up multiple
5496 * AppendRelInfos. But stop if we hit a parent that is not
5497 * RTE_RELATION --- that's a flattened UNION ALL subquery, not
5498 * an inheritance parent.
5499 */
5503 {
5517 /* If the parent is itself a child, continue up. */
5519 }
5521 /*
5522 * In rare cases, the Var may be local to the child table, in
5523 * which case, we've got to live with having no access to this
5524 * column's stats.
5525 */
5529 /* Repeat the access check on this parent rel & column */
5533 /*
5534 * Fine to use the same userid as it's the same in all
5535 * relations of a given inheritance tree.
5536 */
5543 }
5544 }
5545 else
5546 {
5547 /* suppress any possible leakproofness checks later */
5549 }
5550 }
5553 {
5554 /*
5555 * Plain subquery (not one that was converted to an appendrel) or
5556 * non-recursive CTE. In either case, we can try to find out what the
5557 * Var refers to within the subquery. We skip this for appendrel and
5558 * recursive-CTE cases because any column stats we did find would
5559 * likely not be very relevant.
5560 */
5566 /*
5567 * Punt if it's a whole-row var rather than a plain column reference.
5568 */
5572 /*
5573 * Otherwise, find the subquery's planner subroot.
5574 */
5576 {
5579 /*
5580 * Fetch RelOptInfo for subquery. Note that we don't change the
5581 * rel returned in vardata, since caller expects it to be a rel of
5582 * the caller's query level. Because we might already be
5583 * recursing, we can't use that rel pointer either, but have to
5584 * look up the Var's rel afresh.
5585 */
5589 }
5590 else
5591 {
5592 /* CTE case is more difficult */
5594 Index levelsup;
5599 /*
5600 * Find the referenced CTE, and locate the subroot previously made
5601 * for it.
5602 */
5606 {
5610 }
5612 /*
5613 * Note: cte_plan_ids can be shorter than cteList, if we are still
5614 * working on planning the CTEs (ie, this is a side-reference from
5615 * another CTE). So we mustn't use forboth here.
5616 */
5619 {
5624 ndx++;
5625 }
5634 }
5636 /* If the subquery hasn't been planned yet, we have to punt */
5641 /*
5642 * We must use the subquery parsetree as mangled by the planner, not
5643 * the raw version from the RTE, because we need a Var that will refer
5644 * to the subroot's live RelOptInfos. For instance, if any subquery
5645 * pullup happened during planning, Vars in the targetlist might have
5646 * gotten replaced, and we need to see the replacement expressions.
5647 */
5651 /*
5652 * Punt if subquery uses set operations or GROUP BY, as these will
5653 * mash underlying columns' stats beyond recognition. (Set ops are
5654 * particularly nasty; if we forged ahead, we would return stats
5655 * relevant to only the leftmost subselect...) DISTINCT is also
5656 * problematic, but we check that later because there is a possibility
5657 * of learning something even with it.
5658 */
5664 /* Get the subquery output expression referenced by the upper Var */
5667 else
5675 /*
5676 * If subquery uses DISTINCT, we can't make use of any stats for the
5677 * variable ... but, if it's the only DISTINCT column, we are entitled
5678 * to consider it unique. We do the test this way so that it works
5679 * for cases involving DISTINCT ON.
5680 */
5682 {
5686 /* cannot go further */
5688 }
5690 /*
5691 * If the sub-query originated from a view with the security_barrier
5692 * attribute, we must not look at the variable's statistics, though it
5693 * seems all right to notice the existence of a DISTINCT clause. So
5694 * stop here.
5695 *
5696 * This is probably a harsher restriction than necessary; it's
5697 * certainly OK for the selectivity estimator (which is a C function,
5698 * and therefore omnipotent anyway) to look at the statistics. But
5699 * many selectivity estimators will happily *invoke the operator
5700 * function* to try to work out a good estimate - and that's not OK.
5701 * So for now, don't dig down for stats.
5702 */
5706 /* Can only handle a simple Var of subquery's query level */
5709 {
5710 /*
5711 * OK, recurse into the subquery. Note that the original setting
5712 * of vardata->isunique (which will surely be false) is left
5713 * unchanged in this situation. That's what we want, since even
5714 * if the underlying column is unique, the subquery may have
5715 * joined to other tables in a way that creates duplicates.
5716 */
5718 }
5719 }
5720 else
5721 {
5722 /*
5723 * Otherwise, the Var comes from a FUNCTION or VALUES RTE. (We won't
5724 * see RTE_JOIN here because join alias Vars have already been
5725 * flattened.) There's not much we can do with function outputs, but
5726 * maybe someday try to be smarter about VALUES.
5727 */
5728 }
5729 }
5731 /*
5732 * Check whether it is permitted to call func_oid passing some of the
5733 * pg_statistic data in vardata. We allow this either if the user has SELECT
5734 * privileges on the table or column underlying the pg_statistic data or if
5735 * the function is marked leak-proof.
5736 */
5737 bool
5739 {
5753 }
5755 /*
5756 * get_variable_numdistinct
5757 * Estimate the number of distinct values of a variable.
5758 *
5759 * vardata: results of examine_variable
5760 * *isdefault: set to true if the result is a default rather than based on
5761 * anything meaningful.
5762 *
5763 * NB: be careful to produce a positive integral result, since callers may
5764 * compare the result to exact integer counts, or might divide by it.
5765 */
5766 double
5768 {
5775 /*
5776 * Determine the stadistinct value to use. There are cases where we can
5777 * get an estimate even without a pg_statistic entry, or can get a better
5778 * value than is in pg_statistic. Grab stanullfrac too if we can find it
5779 * (otherwise, assume no nulls, for lack of any better idea).
5780 */
5782 {
5783 /* Use the pg_statistic entry */
5784 Form_pg_statistic stats;
5789 }
5791 {
5792 /*
5793 * Special-case boolean columns: presumably, two distinct values.
5794 *
5795 * Are there any other datatypes we should wire in special estimates
5796 * for?
5797 */
5799 }
5801 {
5802 /*
5803 * If the Var represents a column of a VALUES RTE, assume it's unique.
5804 * This could of course be very wrong, but it should tend to be true
5805 * in well-written queries. We could consider examining the VALUES'
5806 * contents to get some real statistics; but that only works if the
5807 * entries are all constants, and it would be pretty expensive anyway.
5808 */
5810 }
5811 else
5812 {
5813 /*
5814 * We don't keep statistics for system columns, but in some cases we
5815 * can infer distinctness anyway.
5816 */
5818 {
5820 {
5830 }
5831 }
5832 else
5835 /*
5836 * XXX consider using estimate_num_groups on expressions?
5837 */
5838 }
5840 /*
5841 * If there is a unique index or DISTINCT clause for the variable, assume
5842 * it is unique no matter what pg_statistic says; the statistics could be
5843 * out of date, or we might have found a partial unique index that proves
5844 * the var is unique for this query. However, we'd better still believe
5845 * the null-fraction statistic.
5846 */
5850 /*
5851 * If we had an absolute estimate, use that.
5852 */
5856 /*
5857 * Otherwise we need to get the relation size; punt if not available.
5858 */
5860 {
5863 }
5866 {
5869 }
5871 /*
5872 * If we had a relative estimate, use that.
5873 */
5877 /*
5878 * With no data, estimate ndistinct = ntuples if the table is small, else
5879 * use default. We use DEFAULT_NUM_DISTINCT as the cutoff for "small" so
5880 * that the behavior isn't discontinuous.
5881 */
5887 }
5889 /*
5890 * get_variable_range
5891 * Estimate the minimum and maximum value of the specified variable.
5892 * If successful, store values in *min and *max, and return true.
5893 * If no data available, return false.
5894 *
5895 * sortop is the "<" comparison operator to use. This should generally
5896 * be "<" not ">", as only the former is likely to be found in pg_statistic.
5897 * The collation must be specified too.
5898 */
5899 static bool
5903 {
5907 int16 typLen;
5909 Oid opfuncoid;
5910 FmgrInfo opproc;
5911 AttStatsSlot sslot;
5913 /*
5914 * XXX It's very tempting to try to use the actual column min and max, if
5915 * we can get them relatively-cheaply with an index probe. However, since
5916 * this function is called many times during join planning, that could
5917 * have unpleasant effects on planning speed. Need more investigation
5918 * before enabling this.
5919 */
5920 #ifdef NOT_USED
5923 #endif
5926 {
5927 /* no stats available, so default result */
5929 }
5931 /*
5932 * If we can't apply the sortop to the stats data, just fail. In
5933 * principle, if there's a histogram and no MCVs, we could return the
5934 * histogram endpoints without ever applying the sortop ... but it's
5935 * probably not worth trying, because whatever the caller wants to do with
5936 * the endpoints would likely fail the security check too.
5937 */
5946 /*
5947 * If there is a histogram with the ordering we want, grab the first and
5948 * last values.
5949 */
5952 ATTSTATSSLOT_VALUES))
5953 {
5955 {
5959 }
5961 }
5963 /*
5964 * Otherwise, if there is a histogram with some other ordering, scan it
5965 * and get the min and max values according to the ordering we want. This
5966 * of course may not find values that are really extremal according to our
5967 * ordering, but it beats ignoring available data.
5968 */
5972 ATTSTATSSLOT_VALUES))
5973 {
5978 }
5980 /*
5981 * If we have most-common-values info, look for extreme MCVs. This is
5982 * needed even if we also have a histogram, since the histogram excludes
5983 * the MCVs. However, if we *only* have MCVs and no histogram, we should
5984 * be pretty wary of deciding that that is a full representation of the
5985 * data. Proceed only if the MCVs represent the whole table (to within
5986 * roundoff error).
5987 */
5992 {
5996 {
6006 }
6013 }
6018 }
6020 /*
6021 * get_stats_slot_range: scan sslot for min/max values
6022 *
6023 * Subroutine for get_variable_range: update min/max/have_data according
6024 * to what we find in the statistics array.
6025 */
6026 static void
6030 {
6037 /* Look up the comparison function, if we didn't already do so */
6041 /* Scan all the slot's values */
6043 {
6045 {
6050 }
6052 collation,
6054 {
6057 }
6059 collation,
6061 {
6064 }
6065 }
6067 /*
6068 * Copy the slot's values, if we found new extreme values.
6069 */
6074 }
6077 /*
6078 * get_actual_variable_range
6079 * Attempt to identify the current *actual* minimum and/or maximum
6080 * of the specified variable, by looking for a suitable btree index
6081 * and fetching its low and/or high values.
6082 * If successful, store values in *min and *max, and return true.
6083 * (Either pointer can be NULL if that endpoint isn't needed.)
6084 * If unsuccessful, return false.
6085 *
6086 * sortop is the "<" comparison operator to use.
6087 * collation is the required collation.
6088 */
6089 static bool
6093 {
6099 /* No hope if no relation or it doesn't have indexes */
6102 /* If it has indexes it must be a plain relation */
6106 /* ignore partitioned tables. Any indexes here are not real indexes */
6110 /* Search through the indexes to see if any match our problem */
6112 {
6114 ScanDirection indexscandir;
6116 /* Ignore non-btree indexes */
6120 /*
6121 * Ignore partial indexes --- we only want stats that cover the entire
6122 * relation.
6123 */
6127 /*
6128 * The index list might include hypothetical indexes inserted by a
6129 * get_relation_info hook --- don't try to access them.
6130 */
6134 /*
6135 * The first index column must match the desired variable, sortop, and
6136 * collation --- but we can use a descending-order index.
6137 */
6143 {
6147 else
6153 else
6157 /* index doesn't match the sortop */
6159 }
6161 /*
6162 * Found a suitable index to extract data from. Set up some data that
6163 * can be used by both invocations of get_actual_variable_endpoint.
6164 */
6165 {
6166 MemoryContext tmpcontext;
6167 MemoryContext oldcontext;
6168 Relation heapRel;
6169 Relation indexRel;
6171 int16 typLen;
6175 /* Make sure any cruft gets recycled when we're done */
6178 ALLOCSET_DEFAULT_SIZES);
6181 /*
6182 * Open the table and index so we can read from them. We should
6183 * already have some type of lock on each.
6184 */
6188 /* build some stuff needed for indexscan execution */
6192 /* set up an IS NOT NULL scan key so that we ignore nulls */
6202 /* If min is requested ... */
6204 {
6206 indexRel,
6207 indexscandir,
6208 scankeys,
6209 typLen,
6210 typByVal,
6211 slot,
6212 oldcontext,
6213 min);
6214 }
6215 else
6216 {
6217 /* If min not requested, still want to fetch max */
6219 }
6221 /* If max is requested, and we didn't already fail ... */
6223 {
6224 /* scan in the opposite direction; all else is the same */
6226 indexRel,
6228 scankeys,
6229 typLen,
6230 typByVal,
6231 slot,
6232 oldcontext,
6233 max);
6234 }
6236 /* Clean everything up */
6245 /* And we're done */
6247 }
6248 }
6251 }
6253 /*
6254 * Get one endpoint datum (min or max depending on indexscandir) from the
6255 * specified index. Return true if successful, false if not.
6256 * On success, endpoint value is stored to *endpointDatum (and copied into
6257 * outercontext).
6258 *
6259 * scankeys is a 1-element scankey array set up to reject nulls.
6260 * typLen/typByVal describe the datatype of the index's first column.
6261 * tableslot is a slot suitable to hold table tuples, in case we need
6262 * to probe the heap.
6263 * (We could compute these values locally, but that would mean computing them
6264 * twice when get_actual_variable_range needs both the min and the max.)
6265 *
6266 * Failure occurs either when the index is empty, or we decide that it's
6267 * taking too long to find a suitable tuple.
6268 */
6269 static bool
6271 Relation indexRel,
6272 ScanDirection indexscandir,
6273 ScanKey scankeys,
6274 int16 typLen,
6277 MemoryContext outercontext,
6279 {
6281 SnapshotData SnapshotNonVacuumable;
6282 IndexScanDesc index_scan;
6286 ItemPointer tid;
6289 MemoryContext oldcontext;
6291 /*
6292 * We use the index-only-scan machinery for this. With mostly-static
6293 * tables that's a win because it avoids a heap visit. It's also a win
6294 * for dynamic data, but the reason is less obvious; read on for details.
6295 *
6296 * In principle, we should scan the index with our current active
6297 * snapshot, which is the best approximation we've got to what the query
6298 * will see when executed. But that won't be exact if a new snap is taken
6299 * before running the query, and it can be very expensive if a lot of
6300 * recently-dead or uncommitted rows exist at the beginning or end of the
6301 * index (because we'll laboriously fetch each one and reject it).
6302 * Instead, we use SnapshotNonVacuumable. That will accept recently-dead
6303 * and uncommitted rows as well as normal visible rows. On the other
6304 * hand, it will reject known-dead rows, and thus not give a bogus answer
6305 * when the extreme value has been deleted (unless the deletion was quite
6306 * recent); that case motivates not using SnapshotAny here.
6307 *
6308 * A crucial point here is that SnapshotNonVacuumable, with
6309 * GlobalVisTestFor(heapRel) as horizon, yields the inverse of the
6310 * condition that the indexscan will use to decide that index entries are
6311 * killable (see heap_hot_search_buffer()). Therefore, if the snapshot
6312 * rejects a tuple (or more precisely, all tuples of a HOT chain) and we
6313 * have to continue scanning past it, we know that the indexscan will mark
6314 * that index entry killed. That means that the next
6315 * get_actual_variable_endpoint() call will not have to re-consider that
6316 * index entry. In this way we avoid repetitive work when this function
6317 * is used a lot during planning.
6318 *
6319 * But using SnapshotNonVacuumable creates a hazard of its own. In a
6320 * recently-created index, some index entries may point at "broken" HOT
6321 * chains in which not all the tuple versions contain data matching the
6322 * index entry. The live tuple version(s) certainly do match the index,
6323 * but SnapshotNonVacuumable can accept recently-dead tuple versions that
6324 * don't match. Hence, if we took data from the selected heap tuple, we
6325 * might get a bogus answer that's not close to the index extremal value,
6326 * or could even be NULL. We avoid this hazard because we take the data
6327 * from the index entry not the heap.
6328 *
6329 * Despite all this care, there are situations where we might find many
6330 * non-visible tuples near the end of the index. We don't want to expend
6331 * a huge amount of time here, so we give up once we've read too many heap
6332 * pages. When we fail for that reason, the caller will end up using
6333 * whatever extremal value is recorded in pg_statistic.
6334 */
6341 /* Set it up for index-only scan */
6345 /* Fetch first/next tuple in specified direction */
6347 {
6351 block,
6353 {
6354 /* Rats, we have to visit the heap to check visibility */
6356 {
6357 /*
6358 * No visible tuple for this index entry, so we need to
6359 * advance to the next entry. Before doing so, count heap
6360 * page fetches and give up if we've done too many.
6361 *
6362 * We don't charge a page fetch if this is the same heap page
6363 * as the previous tuple. This is on the conservative side,
6364 * since other recently-accessed pages are probably still in
6365 * buffers too; but it's good enough for this heuristic.
6366 */
6367 #define VISITED_PAGES_LIMIT 100
6370 {
6372 n_visited_heap_pages++;
6375 }
6378 }
6380 /* We don't actually need the heap tuple for anything */
6383 /*
6384 * We don't care whether there's more than one visible tuple in
6385 * the HOT chain; if any are visible, that's good enough.
6386 */
6387 }
6389 /*
6390 * We expect that btree will return data in IndexTuple not HeapTuple
6391 * format. It's not lossy either.
6392 */
6398 /* OK to deconstruct the index tuple */
6403 /* Shouldn't have got a null, but be careful */
6408 /* Copy the index column value out to caller's context */
6414 }
6421 }
6423 /*
6424 * find_join_input_rel
6425 * Look up the input relation for a join.
6426 *
6427 * We assume that the input relation's RelOptInfo must have been constructed
6428 * already.
6429 */
6432 {
6436 {
6441 else
6443 }
6449 }
6452 /*-------------------------------------------------------------------------
6453 *
6454 * Index cost estimation functions
6455 *
6456 *-------------------------------------------------------------------------
6457 */
6459 /*
6460 * Extract the actual indexquals (as RestrictInfos) from an IndexClause list
6461 */
6462 List *
6464 {
6469 {
6474 {
6478 }
6479 }
6481 }
6483 /*
6484 * Compute the total evaluation cost of the comparison operands in a list
6485 * of index qual expressions. Since we know these will be evaluated just
6486 * once per scan, there's no need to distinguish startup from per-row cost.
6487 *
6488 * This can be used either on the result of get_quals_from_indexclauses(),
6489 * or directly on an indexorderbys list. In both cases, we expect that the
6490 * index key expression is on the left side of binary clauses.
6491 */
6492 Cost
6494 {
6499 {
6502 QualCost index_qual_cost;
6504 /*
6505 * Index quals will have RestrictInfos, indexorderbys won't. Look
6506 * through RestrictInfo if present.
6507 */
6512 {
6516 }
6518 {
6522 }
6524 {
6528 }
6530 {
6532 }
6533 else
6534 {
6538 }
6542 }
6544 }
6546 void
6551 {
6555 Cost indexStartupCost;
6556 Cost indexTotalCost;
6557 Selectivity indexSelectivity;
6570 /*
6571 * If the index is partial, AND the index predicate with the explicitly
6572 * given indexquals to produce a more accurate idea of the index
6573 * selectivity.
6574 */
6577 /*
6578 * If caller didn't give us an estimate for ScalarArrayOpExpr index scans,
6579 * just assume that the number of index descents is the number of distinct
6580 * combinations of array elements from all of the scan's SAOP clauses.
6581 */
6584 {
6587 {
6591 {
6597 }
6598 }
6599 }
6601 /* Estimate the fraction of main-table tuples that will be visited */
6604 JOIN_INNER,
6605 NULL);
6607 /*
6608 * If caller didn't give us an estimate, estimate the number of index
6609 * tuples that will be visited. We do it in this rather peculiar-looking
6610 * way in order to get the right answer for partial indexes.
6611 */
6614 {
6617 /*
6618 * The above calculation counts all the tuples visited across all
6619 * scans induced by ScalarArrayOpExpr nodes. We want to consider the
6620 * average per-indexscan number, so adjust. This is a handy place to
6621 * round to integer, too. (If caller supplied tuple estimate, it's
6622 * responsible for handling these considerations.)
6623 */
6625 }
6627 /*
6628 * We can bound the number of tuples by the index size in any case. Also,
6629 * always estimate at least one tuple is touched, even when
6630 * indexSelectivity estimate is tiny.
6631 */
6637 /*
6638 * Estimate the number of index pages that will be retrieved.
6639 *
6640 * We use the simplistic method of taking a pro-rata fraction of the total
6641 * number of index pages. In effect, this counts only leaf pages and not
6642 * any overhead such as index metapage or upper tree levels.
6643 *
6644 * In practice access to upper index levels is often nearly free because
6645 * those tend to stay in cache under load; moreover, the cost involved is
6646 * highly dependent on index type. We therefore ignore such costs here
6647 * and leave it to the caller to add a suitable charge if needed.
6648 */
6651 else
6654 /* fetch estimated page cost for tablespace containing index */
6657 NULL);
6659 /*
6660 * Now compute the disk access costs.
6661 *
6662 * The above calculations are all per-index-scan. However, if we are in a
6663 * nestloop inner scan, we can expect the scan to be repeated (with
6664 * different search keys) for each row of the outer relation. Likewise,
6665 * ScalarArrayOpExpr quals result in multiple index scans. This creates
6666 * the potential for cache effects to reduce the number of disk page
6667 * fetches needed. We want to estimate the average per-scan I/O cost in
6668 * the presence of caching.
6669 *
6670 * We use the Mackert-Lohman formula (see costsize.c for details) to
6671 * estimate the total number of page fetches that occur. While this
6672 * wasn't what it was designed for, it seems a reasonable model anyway.
6673 * Note that we are counting pages not tuples anymore, so we take N = T =
6674 * index size, as if there were one "tuple" per page.
6675 */
6680 {
6683 /* total page fetches ignoring cache effects */
6686 /* use Mackert and Lohman formula to adjust for cache effects */
6690 root);
6692 /*
6693 * Now compute the total disk access cost, and then report a pro-rated
6694 * share for each outer scan. (Don't pro-rate for ScalarArrayOpExpr,
6695 * since that's internal to the indexscan.)
6696 */
6699 }
6700 else
6701 {
6702 /*
6703 * For a single index scan, we just charge spc_random_page_cost per
6704 * page touched.
6705 */
6707 }
6709 /*
6710 * CPU cost: any complex expressions in the indexquals will need to be
6711 * evaluated once at the start of the scan to reduce them to runtime keys
6712 * to pass to the index AM (see nodeIndexscan.c). We model the per-tuple
6713 * CPU costs as cpu_index_tuple_cost plus one cpu_operator_cost per
6714 * indexqual operator. Because we have numIndexTuples as a per-scan
6715 * number, we have to multiply by num_sa_scans to get the correct result
6716 * for ScalarArrayOpExpr cases. Similarly add in costs for any index
6717 * ORDER BY expressions.
6718 *
6719 * Note: this neglects the possible costs of rechecking lossy operators.
6720 * Detecting that that might be needed seems more expensive than it's
6721 * worth, though, considering all the other inaccuracies here ...
6722 */
6732 /*
6733 * Generic assumption about index correlation: there isn't any.
6734 */
6737 /*
6738 * Return everything to caller.
6739 */
6748 }
6750 /*
6751 * If the index is partial, add its predicate to the given qual list.
6752 *
6753 * ANDing the index predicate with the explicitly given indexquals produces
6754 * a more accurate idea of the index's selectivity. However, we need to be
6755 * careful not to insert redundant clauses, because clauselist_selectivity()
6756 * is easily fooled into computing a too-low selectivity estimate. Our
6757 * approach is to add only the predicate clause(s) that cannot be proven to
6758 * be implied by the given indexquals. This successfully handles cases such
6759 * as a qual "x = 42" used with a partial index "WHERE x >= 40 AND x < 50".
6760 * There are many other cases where we won't detect redundancy, leading to a
6761 * too-low selectivity estimate, which will bias the system in favor of using
6762 * partial indexes where possible. That is not necessarily bad though.
6763 *
6764 * Note that indexQuals contains RestrictInfo nodes while the indpred
6765 * does not, so the output list will be mixed. This is OK for both
6766 * predicate_implied_by() and clauselist_selectivity(), but might be
6767 * problematic if the result were passed to other things.
6768 */
6769 List *
6771 {
6779 {
6785 }
6787 }
6790 void
6795 {
6798 Oid relid;
6799 AttrNumber colnum;
6802 Cost descentCost;
6811 /*
6812 * For a btree scan, only leading '=' quals plus inequality quals for the
6813 * immediately next attribute contribute to index selectivity (these are
6814 * the "boundary quals" that determine the starting and stopping points of
6815 * the index scan). Additional quals can suppress visits to the heap, so
6816 * it's OK to count them in indexSelectivity, but they should not count
6817 * for estimating numIndexTuples. So we must examine the given indexquals
6818 * to find out which ones count as boundary quals. We rely on the
6819 * knowledge that they are given in index column order.
6820 *
6821 * For a RowCompareExpr, we consider only the first column, just as
6822 * rowcomparesel() does.
6823 *
6824 * If there's a ScalarArrayOpExpr in the quals, we'll actually perform up
6825 * to N index descents (not just one), but the ScalarArrayOpExpr's
6826 * operator can be considered to act the same as it normally does.
6827 */
6835 {
6840 {
6841 /* Beginning of a new column's quals */
6845 indexcol++;
6848 }
6850 /* Examine each indexqual associated with this index clause */
6852 {
6859 {
6863 }
6865 {
6869 }
6871 {
6878 /* estimate SA descents by indexBoundQuals only */
6881 }
6883 {
6887 {
6889 /* IS NULL is like = for selectivity purposes */
6891 }
6892 }
6893 else
6897 /* check for equality operator */
6899 {
6905 }
6908 }
6909 }
6911 /*
6912 * If index is unique and we found an '=' clause for each column, we can
6913 * just assume numIndexTuples = 1 and skip the expensive
6914 * clauselist_selectivity calculations. However, a ScalarArrayOp or
6915 * NullTest invalidates that theory, even though it sets eqQualHere.
6916 */
6919 eqQualHere &&
6923 else
6924 {
6926 Selectivity btreeSelectivity;
6928 /*
6929 * If the index is partial, AND the index predicate with the
6930 * index-bound quals to produce a more accurate idea of the number of
6931 * rows covered by the bound conditions.
6932 */
6937 JOIN_INNER,
6938 NULL);
6941 /*
6942 * btree automatically combines individual ScalarArrayOpExpr primitive
6943 * index scans whenever the tuples covered by the next set of array
6944 * keys are close to tuples covered by the current set. That puts a
6945 * natural ceiling on the worst case number of descents -- there
6946 * cannot possibly be more than one descent per leaf page scanned.
6947 *
6948 * Clamp the number of descents to at most 1/3 the number of index
6949 * pages. This avoids implausibly high estimates with low selectivity
6950 * paths, where scans usually require only one or two descents. This
6951 * is most likely to help when there are several SAOP clauses, where
6952 * naively accepting the total number of distinct combinations of
6953 * array elements as the number of descents would frequently lead to
6954 * wild overestimates.
6955 *
6956 * We somewhat arbitrarily don't just make the cutoff the total number
6957 * of leaf pages (we make it 1/3 the total number of pages instead) to
6958 * give the btree code credit for its ability to continue on the leaf
6959 * level with low selectivity scans.
6960 */
6964 /*
6965 * As in genericcostestimate(), we have to adjust for any
6966 * ScalarArrayOpExpr quals included in indexBoundQuals, and then round
6967 * to integer.
6968 *
6969 * It is tempting to make genericcostestimate behave as if SAOP
6970 * clauses work in almost the same way as scalar operators during
6971 * btree scans, making the top-level scan look like a continuous scan
6972 * (as opposed to num_sa_scans-many primitive index scans). After
6973 * all, btree scans mostly work like that at runtime. However, such a
6974 * scheme would badly bias genericcostestimate's simplistic approach
6975 * to calculating numIndexPages through prorating.
6976 *
6977 * Stick with the approach taken by non-native SAOP scans for now.
6978 * genericcostestimate will use the Mackert-Lohman formula to
6979 * compensate for repeat page fetches, even though that definitely
6980 * won't happen during btree scans (not for leaf pages, at least).
6981 * We're usually very pessimistic about the number of primitive index
6982 * scans that will be required, but it's not clear how to do better.
6983 */
6985 }
6987 /*
6988 * Now do generic index cost estimation.
6989 */
6995 /*
6996 * Add a CPU-cost component to represent the costs of initial btree
6997 * descent. We don't charge any I/O cost for touching upper btree levels,
6998 * since they tend to stay in cache, but we still have to do about log2(N)
6999 * comparisons to descend a btree of N leaf tuples. We charge one
7000 * cpu_operator_cost per comparison.
7001 *
7002 * If there are ScalarArrayOpExprs, charge this once per estimated SA
7003 * index descent. The ones after the first one are not startup cost so
7004 * far as the overall plan goes, so just add them to "total" cost.
7005 */
7007 {
7011 }
7013 /*
7014 * Even though we're not charging I/O cost for touching upper btree pages,
7015 * it's still reasonable to charge some CPU cost per page descended
7016 * through. Moreover, if we had no such charge at all, bloated indexes
7017 * would appear to have the same search cost as unbloated ones, at least
7018 * in cases where only a single leaf page is expected to be visited. This
7019 * cost is somewhat arbitrarily set at 50x cpu_operator_cost per page
7020 * touched. The number of such pages is btree tree height plus one (ie,
7021 * we charge for the leaf page too). As above, charge once per estimated
7022 * SA index descent.
7023 */
7028 /*
7029 * If we can get an estimate of the first column's ordering correlation C
7030 * from pg_statistic, estimate the index correlation as C for a
7031 * single-column index, or C * 0.75 for multiple columns. (The idea here
7032 * is that multiple columns dilute the importance of the first column's
7033 * ordering, but don't negate it entirely. Before 8.0 we divided the
7034 * correlation by the number of columns, but that seems too strong.)
7035 */
7037 {
7038 /* Simple variable --- look to stats for the underlying table */
7048 {
7049 /*
7050 * The hook took control of acquiring a stats tuple. If it did
7051 * supply a tuple, it'd better have supplied a freefunc.
7052 */
7056 }
7057 else
7058 {
7064 }
7065 }
7066 else
7067 {
7068 /* Expression --- maybe there are stats for the index itself */
7074 {
7075 /*
7076 * The hook took control of acquiring a stats tuple. If it did
7077 * supply a tuple, it'd better have supplied a freefunc.
7078 */
7082 }
7083 else
7084 {
7090 }
7091 }
7094 {
7095 Oid sortop;
7096 AttStatsSlot sslot;
7101 BTLessStrategyNumber);
7105 ATTSTATSSLOT_NUMBERS))
7106 {
7117 else
7121 }
7122 }
7131 }
7133 void
7138 {
7143 /*
7144 * A hash index has no descent costs as such, since the index AM can go
7145 * directly to the target bucket after computing the hash value. There
7146 * are a couple of other hash-specific costs that we could conceivably add
7147 * here, though:
7148 *
7149 * Ideally we'd charge spc_random_page_cost for each page in the target
7150 * bucket, not just the numIndexPages pages that genericcostestimate
7151 * thought we'd visit. However in most cases we don't know which bucket
7152 * that will be. There's no point in considering the average bucket size
7153 * because the hash AM makes sure that's always one page.
7154 *
7155 * Likewise, we could consider charging some CPU for each index tuple in
7156 * the bucket, if we knew how many there were. But the per-tuple cost is
7157 * just a hash value comparison, not a general datatype-dependent
7158 * comparison, so any such charge ought to be quite a bit less than
7159 * cpu_operator_cost; which makes it probably not worth worrying about.
7160 *
7161 * A bigger issue is that chance hash-value collisions will result in
7162 * wasted probes into the heap. We don't currently attempt to model this
7163 * cost on the grounds that it's rare, but maybe it's not rare enough.
7164 * (Any fix for this ought to consider the generic lossy-operator problem,
7165 * though; it's not entirely hash-specific.)
7166 */
7173 }
7175 void
7180 {
7183 Cost descentCost;
7187 /*
7188 * We model index descent costs similarly to those for btree, but to do
7189 * that we first need an idea of the tree height. We somewhat arbitrarily
7190 * assume that the fanout is 100, meaning the tree height is at most
7191 * log100(index->pages).
7192 *
7193 * Although this computation isn't really expensive enough to require
7194 * caching, we might as well use index->tree_height to cache it.
7195 */
7197 {
7200 else
7202 }
7204 /*
7205 * Add a CPU-cost component to represent the costs of initial descent. We
7206 * just use log(N) here not log2(N) since the branching factor isn't
7207 * necessarily two anyway. As for btree, charge once per SA scan.
7208 */
7210 {
7214 }
7216 /*
7217 * Likewise add a per-page charge, calculated the same as for btrees.
7218 */
7228 }
7230 void
7235 {
7238 Cost descentCost;
7242 /*
7243 * We model index descent costs similarly to those for btree, but to do
7244 * that we first need an idea of the tree height. We somewhat arbitrarily
7245 * assume that the fanout is 100, meaning the tree height is at most
7246 * log100(index->pages).
7247 *
7248 * Although this computation isn't really expensive enough to require
7249 * caching, we might as well use index->tree_height to cache it.
7250 */
7252 {
7255 else
7257 }
7259 /*
7260 * Add a CPU-cost component to represent the costs of initial descent. We
7261 * just use log(N) here not log2(N) since the branching factor isn't
7262 * necessarily two anyway. As for btree, charge once per SA scan.
7263 */
7265 {
7269 }
7271 /*
7272 * Likewise add a per-page charge, calculated the same as for btrees.
7273 */
7283 }
7286 /*
7287 * Support routines for gincostestimate
7288 */
7291 {
7300 /*
7301 * Estimate the number of index terms that need to be searched for while
7302 * testing the given GIN query, and increment the counts in *counts
7303 * appropriately. If the query is unsatisfiable, return false.
7304 */
7305 static bool
7309 {
7310 FmgrInfo flinfo;
7311 Oid extractProcOid;
7312 Oid collation;
7314 Oid lefttype,
7315 righttype;
7321 int32 i;
7325 /*
7326 * Get the operator's strategy number and declared input data types within
7327 * the index opfamily. (We don't need the latter, but we use
7328 * get_op_opfamily_properties because it will throw error if it fails to
7329 * find a matching pg_amop entry.)
7330 */
7334 /*
7335 * GIN always uses the "default" support functions, which are those with
7336 * lefttype == righttype == the opclass' opcintype (see
7337 * IndexSupportInitialize in relcache.c).
7338 */
7342 GIN_EXTRACTQUERY_PROC);
7345 {
7346 /* should not happen; throw same error as index_getprocinfo */
7350 }
7352 /*
7353 * Choose collation to pass to extractProc (should match initGinState).
7354 */
7357 else
7365 collation,
7366 query,
7375 {
7376 /* No match is possible */
7378 }
7381 {
7382 /*
7383 * For partial match we haven't any information to estimate number of
7384 * matched entries in index, so, we just estimate it as 100
7385 */
7388 else
7392 }
7395 {
7397 }
7399 {
7400 /* Treat "include empty" like an exact-match item */
7404 }
7405 else
7406 {
7407 /* It's GIN_SEARCH_MODE_ALL */
7409 }
7412 }
7414 /*
7415 * Estimate the number of index terms that need to be searched for while
7416 * testing the given GIN index clause, and increment the counts in *counts
7417 * appropriately. If the query is unsatisfiable, return false.
7418 */
7419 static bool
7425 {
7429 /* aggressively reduce to a constant, and look through relabeling */
7435 /*
7436 * It's impossible to call extractQuery method for unknown operand. So
7437 * unless operand is a Const we can't do much; just assume there will be
7438 * one ordinary search entry from the operand at runtime.
7439 */
7441 {
7445 }
7447 /* If Const is null, there can be no matches */
7451 /* Otherwise, apply extractQuery and get the actual term counts */
7454 counts);
7455 }
7457 /*
7458 * Estimate the number of index terms that need to be searched for while
7459 * testing the given GIN index clause, and increment the counts in *counts
7460 * appropriately. If the query is unsatisfiable, return false.
7461 *
7462 * A ScalarArrayOpExpr will give rise to N separate indexscans at runtime,
7463 * each of which involves one value from the RHS array, plus all the
7464 * non-array quals (if any). To model this, we average the counts across
7465 * the RHS elements, and add the averages to the counts in *counts (which
7466 * correspond to per-indexscan costs). We also multiply counts->arrayScans
7467 * by N, causing gincostestimate to scale up its estimates accordingly.
7468 */
7469 static bool
7476 {
7480 int16 elmlen;
7486 GinQualCounts arraycounts;
7492 /* aggressively reduce to a constant, and look through relabeling */
7498 /*
7499 * It's impossible to call extractQuery method for unknown operand. So
7500 * unless operand is a Const we can't do much; just assume there will be
7501 * one ordinary search entry from each array entry at runtime, and fall
7502 * back on a probably-bad estimate of the number of array entries.
7503 */
7505 {
7510 }
7512 /* If Const is null, there can be no matches */
7516 /* Otherwise, extract the array elements and iterate over them */
7528 {
7529 GinQualCounts elemcounts;
7531 /* NULL can't match anything, so ignore, as the executor will */
7535 /* Otherwise, apply extractQuery and get the actual term counts */
7540 {
7541 /* We ignore array elements that are unsatisfiable patterns */
7542 numPossible++;
7546 {
7547 /*
7548 * Full index scan will be required. We treat this as if
7549 * every key in the index had been listed in the query; is
7550 * that reasonable?
7551 */
7555 }
7559 }
7560 }
7563 {
7564 /* No satisfiable patterns in the array */
7566 }
7568 /*
7569 * Now add the averages to the global counts. This will give us an
7570 * estimate of the average number of terms searched for in each indexscan,
7571 * including contributions from both array and non-array quals.
7572 */
7580 }
7582 /*
7583 * GIN has search behavior completely different from other index types
7584 */
7585 void
7590 {
7597 numDataPages,
7598 numPendingPages,
7599 numEntries;
7600 GinQualCounts counts;
7605 dataPagesFetched,
7606 dataPagesFetchedBySel;
7608 qual_arg_cost,
7609 spc_random_page_cost,
7610 outer_scans;
7611 Cost descentCost;
7612 Relation indexRel;
7613 GinStatsData ginStats;
7617 /*
7618 * Obtain statistical information from the meta page, if possible. Else
7619 * set ginStats to zeroes, and we'll cope below.
7620 */
7622 {
7623 /* Lock should have already been obtained in plancat.c */
7627 }
7628 else
7629 {
7631 }
7633 /*
7634 * Assuming we got valid (nonzero) stats at all, nPendingPages can be
7635 * trusted, but the other fields are data as of the last VACUUM. We can
7636 * scale them up to account for growth since then, but that method only
7637 * goes so far; in the worst case, the stats might be for a completely
7638 * empty index, and scaling them will produce pretty bogus numbers.
7639 * Somewhat arbitrarily, set the cutoff for doing scaling at 4X growth; if
7640 * it's grown more than that, fall back to estimating things only from the
7641 * assumed-accurate index size. But we'll trust nPendingPages in any case
7642 * so long as it's not clearly insane, ie, more than the index size.
7643 */
7646 else
7652 {
7653 /*
7654 * OK, the stats seem close enough to sane to be trusted. But we
7655 * still need to scale them by the ratio numPages / nTotalPages to
7656 * account for growth since the last VACUUM.
7657 */
7663 /* ensure we didn't round up too much */
7667 }
7668 else
7669 {
7670 /*
7671 * We might get here because it's a hypothetical index, or an index
7672 * created pre-9.1 and never vacuumed since upgrading (in which case
7673 * its stats would read as zeroes), or just because it's grown too
7674 * much since the last VACUUM for us to put our faith in scaling.
7675 *
7676 * Invent some plausible internal statistics based on the index page
7677 * count (and clamp that to at least 10 pages, just in case). We
7678 * estimate that 90% of the index is entry pages, and the rest is data
7679 * pages. Estimate 100 entries per entry page; this is rather bogus
7680 * since it'll depend on the size of the keys, but it's more robust
7681 * than trying to predict the number of entries per heap tuple.
7682 */
7687 }
7689 /* In an empty index, numEntries could be zero. Avoid divide-by-zero */
7693 /*
7694 * If the index is partial, AND the index predicate with the index-bound
7695 * quals to produce a more accurate idea of the number of rows covered by
7696 * the bound conditions.
7697 */
7700 /* Estimate the fraction of main-table tuples that will be visited */
7703 JOIN_INNER,
7704 NULL);
7706 /* fetch estimated page cost for tablespace containing index */
7709 NULL);
7711 /*
7712 * Generic assumption about index correlation: there isn't any.
7713 */
7716 /*
7717 * Examine quals to estimate number of search entries & partial matches
7718 */
7724 {
7729 {
7734 {
7736 index,
7742 }
7744 {
7746 index,
7749 numEntries,
7753 }
7754 else
7755 {
7756 /* shouldn't be anything else for a GIN index */
7759 }
7760 }
7761 }
7763 /* Fall out if there were any provably-unsatisfiable quals */
7765 {
7770 }
7772 /*
7773 * If attribute has a full scan and at the same time doesn't have normal
7774 * scan, then we'll have to scan all non-null entries of that attribute.
7775 * Currently, we don't have per-attribute statistics for GIN. Thus, we
7776 * must assume the whole GIN index has to be scanned in this case.
7777 */
7780 {
7782 {
7785 }
7786 }
7789 {
7790 /*
7791 * Full index scan will be required. We treat this as if every key in
7792 * the index had been listed in the query; is that reasonable?
7793 */
7797 }
7799 /* Will we have more than one iteration of a nestloop scan? */
7802 /*
7803 * Compute cost to begin scan, first of all, pay attention to pending
7804 * list.
7805 */
7808 /*
7809 * Estimate number of entry pages read. We need to do
7810 * counts.searchEntries searches. Use a power function as it should be,
7811 * but tuples on leaf pages usually is much greater. Here we include all
7812 * searches in entry tree, including search of first entry in partial
7813 * match algorithm
7814 */
7817 /*
7818 * Add an estimate of entry pages read by partial match algorithm. It's a
7819 * scan over leaf pages in entry tree. We haven't any useful stats here,
7820 * so estimate it as proportion. Because counts.partialEntries is really
7821 * pretty bogus (see code above), it's possible that it is more than
7822 * numEntries; clamp the proportion to ensure sanity.
7823 */
7829 /*
7830 * Partial match algorithm reads all data pages before doing actual scan,
7831 * so it's a startup cost. Again, we haven't any useful stats here, so
7832 * estimate it as proportion.
7833 */
7839 /*
7840 * Add a CPU-cost component to represent the costs of initial entry btree
7841 * descent. We don't charge any I/O cost for touching upper btree levels,
7842 * since they tend to stay in cache, but we still have to do about log2(N)
7843 * comparisons to descend a btree of N leaf tuples. We charge one
7844 * cpu_operator_cost per comparison.
7845 *
7846 * If there are ScalarArrayOpExprs, charge this once per SA scan. The
7847 * ones after the first one are not startup cost so far as the overall
7848 * plan is concerned, so add them only to "total" cost.
7849 */
7851 {
7855 }
7857 /*
7858 * Add a cpu cost per entry-page fetched. This is not amortized over a
7859 * loop.
7860 */
7862 *indexTotalCost += entryPagesFetched * counts.arrayScans * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
7864 /*
7865 * Add a cpu cost per data-page fetched. This is also not amortized over a
7866 * loop. Since those are the data pages from the partial match algorithm,
7867 * charge them as startup cost.
7868 */
7871 /*
7872 * Since we add the startup cost to the total cost later on, remove the
7873 * initial arrayscan from the total.
7874 */
7875 *indexTotalCost += dataPagesFetched * (counts.arrayScans - 1) * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
7877 /*
7878 * Calculate cache effects if more than one scan due to nestloops or array
7879 * quals. The result is pro-rated per nestloop scan, but the array qual
7880 * factor shouldn't be pro-rated (compare genericcostestimate).
7881 */
7883 {
7894 }
7896 /*
7897 * Here we use random page cost because logically-close pages could be far
7898 * apart on disk.
7899 */
7902 /*
7903 * Now compute the number of data pages fetched during the scan.
7904 *
7905 * We assume every entry to have the same number of items, and that there
7906 * is no overlap between them. (XXX: tsvector and array opclasses collect
7907 * statistics on the frequency of individual keys; it would be nice to use
7908 * those here.)
7909 */
7912 /*
7913 * If there is a lot of overlap among the entries, in particular if one of
7914 * the entries is very frequent, the above calculation can grossly
7915 * under-estimate. As a simple cross-check, calculate a lower bound based
7916 * on the overall selectivity of the quals. At a minimum, we must read
7917 * one item pointer for each matching entry.
7918 *
7919 * The width of each item pointer varies, based on the level of
7920 * compression. We don't have statistics on that, but an average of
7921 * around 3 bytes per item is fairly typical.
7922 */
7928 /* Add one page cpu-cost to the startup cost */
7931 /*
7932 * Add once again a CPU-cost for those data pages, before amortizing for
7933 * cache.
7934 */
7935 *indexTotalCost += dataPagesFetched * counts.arrayScans * DEFAULT_PAGE_CPU_MULTIPLIER * cpu_operator_cost;
7937 /* Account for cache effects, the same as above */
7939 {
7945 }
7947 /* And apply random_page_cost as the cost per page */
7951 /*
7952 * Add on index qual eval costs, much as in genericcostestimate. We charge
7953 * cpu but we can disregard indexorderbys, since GIN doesn't support
7954 * those.
7955 */
7962 /*
7963 * Add a cpu cost per search entry, corresponding to the actual visited
7964 * entries.
7965 */
7967 /* Now add a cpu cost per tuple in the posting lists / trees */
7970 }
7972 /*
7973 * BRIN has search behavior completely different from other index types
7974 */
7975 void
7980 {
7986 Cost spc_seq_page_cost;
7987 Cost spc_random_page_cost;
7990 BrinStatsData statsData;
7995 Relation indexRel;
7997 VariableStatData vardata;
8001 /* fetch estimated page cost for the tablespace containing the index */
8006 /*
8007 * Obtain some data from the index itself, if possible. Otherwise invent
8008 * some plausible internal statistics based on the relation page count.
8009 */
8011 {
8012 /*
8013 * A lock should have already been obtained on the index in plancat.c.
8014 */
8019 /* work out the actual number of ranges in the index */
8022 }
8023 else
8024 {
8025 /*
8026 * Assume default number of pages per range, and estimate the number
8027 * of ranges based on that.
8028 */
8034 }
8036 /*
8037 * Compute index correlation
8038 *
8039 * Because we can use all index quals equally when scanning, we can use
8040 * the largest correlation (in absolute value) among columns used by the
8041 * query. Start at zero, the worst possible case. If we cannot find any
8042 * correlation statistics, we will keep it as 0.
8043 */
8047 {
8051 /* attempt to lookup stats in relation for this index column */
8053 {
8054 /* Simple variable -- look to stats for the underlying table */
8057 {
8058 /*
8059 * The hook took control of acquiring a stats tuple. If it
8060 * did supply a tuple, it'd better have supplied a freefunc.
8061 */
8065 }
8066 else
8067 {
8074 }
8075 }
8076 else
8077 {
8078 /*
8079 * Looks like we've found an expression column in the index. Let's
8080 * see if there's any stats for it.
8081 */
8083 /* get the attnum from the 0-based index. */
8088 {
8089 /*
8090 * The hook took control of acquiring a stats tuple. If it
8091 * did supply a tuple, it'd better have supplied a freefunc.
8092 */
8096 }
8097 else
8098 {
8104 }
8105 }
8108 {
8109 AttStatsSlot sslot;
8113 ATTSTATSSLOT_NUMBERS))
8114 {
8124 }
8125 }
8128 }
8134 /*
8135 * Now calculate the minimum possible ranges we could match with if all of
8136 * the rows were in the perfect order in the table's heap.
8137 */
8140 /*
8141 * Now estimate the number of ranges that we'll touch by using the
8142 * indexCorrelation from the stats. Careful not to divide by zero (note
8143 * we're using the absolute value of the correlation).
8144 */
8147 else
8150 /* we expect to visit this portion of the table */
8157 /*
8158 * Compute the index qual costs, much as in genericcostestimate, to add to
8159 * the index costs. We can disregard indexorderbys, since BRIN doesn't
8160 * support those.
8161 */
8164 /*
8165 * Compute the startup cost as the cost to read the whole revmap
8166 * sequentially, including the cost to execute the index quals.
8167 */
8172 /*
8173 * To read a BRIN index there might be a bit of back and forth over
8174 * regular pages, as revmap might point to them out of sequential order;
8175 * calculate the total cost as reading the whole index in random order.
8176 */
8180 /*
8181 * Charge a small amount per range tuple which we expect to match to. This
8182 * is meant to reflect the costs of manipulating the bitmap. The BRIN scan
8183 * will set a bit for each page in the range when we find a matching
8184 * range, so we must multiply the charge by the number of pages in the
8185 * range.
8186 */
8191 }