]> granicus.if.org Git - postgresql/commit
In planner, don't assume that empty parent tables aren't really empty.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 14 Jul 2011 21:30:57 +0000 (17:30 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 14 Jul 2011 21:31:12 +0000 (17:31 -0400)
commitcf82452855b76611b73ab8d4dde75f1758d8bf28
treeef19991187a8553574ad4354e01442aaedfd9913
parenta3678ab2147fad8e64ea5198a545fb902e6d65f4
In planner, don't assume that empty parent tables aren't really empty.

There's a heuristic in estimate_rel_size() to clamp the minimum size
estimate for a table to 10 pages, unless we can see that vacuum or analyze
has been run (and set relpages to something nonzero, so this will always
happen for a table that's actually empty).  However, it would be better
not to do this for inheritance parent tables, which very commonly are
really empty and can be expected to stay that way.  Per discussion of a
recent pgsql-performance report from Anish Kejariwal.  Also prevent it
from happening for indexes (although this is more in the nature of
documentation, since CREATE INDEX normally initializes relpages to
something nonzero anyway).

Back-patch to 9.0, because the ability to collect statistics across a
whole inheritance tree has improved the planner's estimates to the point
where this relatively small error makes a significant difference.  In the
referenced report, merge or hash joins were incorrectly estimated as
cheaper than a nestloop with inner indexscan on the inherited table.
That was less likely before 9.0 because the lack of inherited stats would
have resulted in a default (and rather pessimistic) estimate of the cost
of a merge or hash join.
src/backend/optimizer/util/plancat.c