Fix misestimation of n_distinct for a nearly-unique column with many nulls.
authorTom Lane <[email protected]>
Sun, 7 Aug 2016 22:52:02 +0000 (18:52 -0400)
committerTom Lane <[email protected]>
Sun, 7 Aug 2016 22:52:02 +0000 (18:52 -0400)
If ANALYZE found no repeated non-null entries in its sample, it set the
column's stadistinct value to -1.0, intending to indicate that the entries
are all distinct.  But what this value actually means is that the number
of distinct values is 100% of the table's rowcount, and thus it was
overestimating the number of distinct values by however many nulls there
are.  This could lead to very poor selectivity estimates, as for example
in a recent report from Andreas Joseph Krogh.  We should discount the
stadistinct value by whatever we've estimated the nulls fraction to be.
(That is what will happen if we choose to use a negative stadistinct for
a column that does have repeated entries, so this code path was just
inconsistent.)

In addition to fixing the stadistinct entries stored by several different
ANALYZE code paths, adjust the logic where get_variable_numdistinct()
forces an "all distinct" estimate on the basis of finding a relevant unique
index.  Unique indexes don't reject nulls, so there's no reason to assume
that the null fraction doesn't apply.

Back-patch to all supported branches.  Back-patching is a bit of a judgment
call, but this problem seems to affect only a few users (else we'd have
identified it long ago), and it's bad enough when it does happen that
destabilizing plan choices in a worse direction seems unlikely.

Patch by me, with documentation wording suggested by Dean Rasheed

Report: <VisenaEmail.26.df42f82acae38a58.156463942b8@tc7-visena>
Discussion: <16143.1470350371@sss.pgh.pa.us>

doc/src/sgml/catalogs.sgml
src/backend/commands/analyze.c
src/backend/tsearch/ts_typanalyze.c
src/backend/utils/adt/selfuncs.c
src/include/catalog/pg_statistic.h

index 9a9b3c4f5a36373fb097822b9d5375919950c483..47efe9f2cc0be7ba1626326c03316f9cb7015d81 100644 (file)
       <entry>The number of distinct nonnull data values in the column.
       A value greater than zero is the actual number of distinct values.
       A value less than zero is the negative of a multiplier for the number
-      of rows in the table; for example, a column in which values appear about
-      twice on the average could be represented by
-      <structfield>stadistinct</> = -0.5.
+      of rows in the table; for example, a column in which about 80% of the
+      values are nonnull and each nonnull value appears about twice on
+      average could be represented by <structfield>stadistinct</> = -0.4.
       A zero value means the number of distinct values is unknown.
       </entry>
      </row>
index a4200b5549b259f3e4c503b63bdbf4b4d3af6e55..1afa12e5f5d025bcc974a810eba0321033c30b15 100644 (file)
@@ -2096,8 +2096,11 @@ compute_minimal_stats(VacAttrStatsP stats,
 
        if (nmultiple == 0)
        {
-           /* If we found no repeated values, assume it's a unique column */
-           stats->stadistinct = -1.0;
+           /*
+            * If we found no repeated non-null values, assume it's a unique
+            * column; but be sure to discount for any nulls we found.
+            */
+           stats->stadistinct = -1.0 * (1.0 - stats->stanullfrac);
        }
        else if (track_cnt < track_max && toowide_cnt == 0 &&
                 nmultiple == track_cnt)
@@ -2444,8 +2447,11 @@ compute_scalar_stats(VacAttrStatsP stats,
 
        if (nmultiple == 0)
        {
-           /* If we found no repeated values, assume it's a unique column */
-           stats->stadistinct = -1.0;
+           /*
+            * If we found no repeated non-null values, assume it's a unique
+            * column; but be sure to discount for any nulls we found.
+            */
+           stats->stadistinct = -1.0 * (1.0 - stats->stanullfrac);
        }
        else if (toowide_cnt == 0 && nmultiple == ndistinct)
        {
@@ -2749,7 +2755,7 @@ compute_scalar_stats(VacAttrStatsP stats,
        else
            stats->stawidth = stats->attrtype->typlen;
        /* Assume all too-wide values are distinct, so it's a unique column */
-       stats->stadistinct = -1.0;
+       stats->stadistinct = -1.0 * (1.0 - stats->stanullfrac);
    }
    else if (null_cnt > 0)
    {
index e2e1afdc6bf9d0ccc6749238f6d1fe60514d4097..2bc13b234c45579b504f696c612e0fdd62b83142 100644 (file)
@@ -295,7 +295,7 @@ compute_tsvector_stats(VacAttrStats *stats,
        stats->stawidth = total_width / (double) nonnull_cnt;
 
        /* Assume it's a unique column (see notes above) */
-       stats->stadistinct = -1.0;
+       stats->stadistinct = -1.0 * (1.0 - stats->stanullfrac);
 
        /*
         * Construct an array of the interesting hashtable items, that is,
index 59dcc30106ab8f62a55247404acb6477c43cdd72..9b377161ba88d8d78e3651dcdd80a3cbe660908d 100644 (file)
@@ -4623,6 +4623,7 @@ double
 get_variable_numdistinct(VariableStatData *vardata, bool *isdefault)
 {
    double      stadistinct;
+   double      stanullfrac = 0.0;
    double      ntuples;
 
    *isdefault = false;
@@ -4630,7 +4631,8 @@ get_variable_numdistinct(VariableStatData *vardata, bool *isdefault)
    /*
     * Determine the stadistinct value to use.  There are cases where we can
     * get an estimate even without a pg_statistic entry, or can get a better
-    * value than is in pg_statistic.
+    * value than is in pg_statistic.  Grab stanullfrac too if we can find it
+    * (otherwise, assume no nulls, for lack of any better idea).
     */
    if (HeapTupleIsValid(vardata->statsTuple))
    {
@@ -4639,6 +4641,7 @@ get_variable_numdistinct(VariableStatData *vardata, bool *isdefault)
 
        stats = (Form_pg_statistic) GETSTRUCT(vardata->statsTuple);
        stadistinct = stats->stadistinct;
+       stanullfrac = stats->stanullfrac;
    }
    else if (vardata->vartype == BOOLOID)
    {
@@ -4662,7 +4665,7 @@ get_variable_numdistinct(VariableStatData *vardata, bool *isdefault)
            {
                case ObjectIdAttributeNumber:
                case SelfItemPointerAttributeNumber:
-                   stadistinct = -1.0; /* unique */
+                   stadistinct = -1.0; /* unique (and all non null) */
                    break;
                case TableOidAttributeNumber:
                    stadistinct = 1.0;  /* only 1 value */
@@ -4684,10 +4687,11 @@ get_variable_numdistinct(VariableStatData *vardata, bool *isdefault)
     * If there is a unique index or DISTINCT clause for the variable, assume
     * it is unique no matter what pg_statistic says; the statistics could be
     * out of date, or we might have found a partial unique index that proves
-    * the var is unique for this query.
+    * the var is unique for this query.  However, we'd better still believe
+    * the null-fraction statistic.
     */
    if (vardata->isunique)
-       stadistinct = -1.0;
+       stadistinct = -1.0 * (1.0 - stanullfrac);
 
    /*
     * If we had an absolute estimate, use that.
index 0d4f69a8e98831e4b6e4d48f8be6126330f0809b..fc5d120e1e5b152d30ddb72b5f7fe335b1ab27b6 100644 (file)
@@ -57,13 +57,14 @@ CATALOG(pg_statistic,2619) BKI_WITHOUT_OIDS
     *      > 0     actual number of distinct values
     *      < 0     negative of multiplier for number of rows
     * The special negative case allows us to cope with columns that are
-    * unique (stadistinct = -1) or nearly so (for example, a column in
-    * which values appear about twice on the average could be represented
-    * by stadistinct = -0.5).  Because the number-of-rows statistic in
-    * pg_class may be updated more frequently than pg_statistic is, it's
-    * important to be able to describe such situations as a multiple of
-    * the number of rows, rather than a fixed number of distinct values.
-    * But in other cases a fixed number is correct (eg, a boolean column).
+    * unique (stadistinct = -1) or nearly so (for example, a column in which
+    * non-null values appear about twice on the average could be represented
+    * by stadistinct = -0.5 if there are no nulls, or -0.4 if 20% of the
+    * column is nulls).  Because the number-of-rows statistic in pg_class may
+    * be updated more frequently than pg_statistic is, it's important to be
+    * able to describe such situations as a multiple of the number of rows,
+    * rather than a fixed number of distinct values.  But in other cases a
+    * fixed number is correct (eg, a boolean column).
     * ----------------
     */
    float4      stadistinct;