pgsql: In planner, don't assume that empty parent tables aren't really
От | Tom Lane |
---|---|
Тема | pgsql: In planner, don't assume that empty parent tables aren't really |
Дата | |
Msg-id | E1QhTgq-0000ps-PT@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
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. Branch ------ REL9_0_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/0dd46a776651b2cb49c120a2deb169526ad4afb8 Modified Files -------------- src/backend/optimizer/util/plancat.c | 44 +++++++++++++++++++++++---------- 1 files changed, 30 insertions(+), 14 deletions(-)
В списке pgsql-committers по дате отправления: