diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-11-29 18:00:49 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-11-29 18:00:56 -0500 |
| commit | ca5f88502096a39f831da74eb02ec9eb3310616d (patch) | |
| tree | e98bfee99087887dadc6bd243852ac6f42155db6 /src/backend/utils/adt/selfuncs.c | |
| parent | 96fb4c90e3b227f3f1770fd2f7ea1e0478a4d37c (diff) | |
| download | postgresql-ca5f88502096a39f831da74eb02ec9eb3310616d.tar.gz postgresql-ca5f88502096a39f831da74eb02ec9eb3310616d.zip | |
Improve eqjoinsel_semi's behavior for small inner relations with no stats.
If we don't have any MCV statistics for the inner relation, and we don't
trust its numdistinct estimate either, eqjoinsel_semi falls back to a very
conservative estimate (that 50% of the outer rows have matches). This is
particularly problematic if the inner relation is completely empty, since
then even an explicit ANALYZE won't produce any pg_statistic entries,
so there's no way to budge the planner off the bad estimate.
We'd produce a better estimate in such cases if we used the nd2/nd1
selectivity heuristic, so an easy fix is to treat the nd2 estimate as
non-default if we derive it from clamping to the inner rel's rowcount
estimate. This won't fix every related case (mainly because the rowcount
estimate might be larger than DEFAULT_NUM_DISTINCT), but it seems like a
sane extension of the existing logic, so let's apply the change in HEAD
and see if anyone complains. Per bug #14438 from Nikolay Nikitin.
Report: https://postgr.es/m/20161128182113.6527.58926@wrigleys.postgresql.org
Discussion: https://postgr.es/m/31089.1480384713@sss.pgh.pa.us
Diffstat (limited to 'src/backend/utils/adt/selfuncs.c')
| -rw-r--r-- | src/backend/utils/adt/selfuncs.c | 18 |
1 files changed, 16 insertions, 2 deletions
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c index 56943f2a87a..4973396b80d 100644 --- a/src/backend/utils/adt/selfuncs.c +++ b/src/backend/utils/adt/selfuncs.c @@ -2511,10 +2511,24 @@ eqjoinsel_semi(Oid operator, * We can apply this clamping both with respect to the base relation from * which the join variable comes (if there is just one), and to the * immediate inner input relation of the current join. + * + * If we clamp, we can treat nd2 as being a non-default estimate; it's not + * great, maybe, but it didn't come out of nowhere either. This is most + * helpful when the inner relation is empty and consequently has no stats. */ if (vardata2->rel) - nd2 = Min(nd2, vardata2->rel->rows); - nd2 = Min(nd2, inner_rel->rows); + { + if (nd2 >= vardata2->rel->rows) + { + nd2 = vardata2->rel->rows; + isdefault2 = false; + } + } + if (nd2 >= inner_rel->rows) + { + nd2 = inner_rel->rows; + isdefault2 = false; + } if (HeapTupleIsValid(vardata1->statsTuple)) { |