Account better for planning cost when choosing whether to use custom plans.

The previous coding in plancache.c essentially used 10% of the estimated
runtime as its cost estimate for planning. This can be pretty bogus,
especially when the estimated runtime is very small, such as in a simple
expression plan created by plpgsql, or a simple INSERT ... VALUES.

While we don't have a really good handle on how planning time compares
to runtime, it seems reasonable to use an estimate based on the number of
relations referenced in the query, with a rather large multiplier. This
patch uses 1000 * cpu_operator_cost * (nrelations + 1), so that even a
trivial query will be charged 1000 * cpu_operator_cost for planning.
This should address the problem reported by Marc Cousin and others that
9.2 and up prefer custom plans in cases where the planning time greatly
exceeds what can be saved.

Branch
------
REL9_3_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/a5f11e24a4d1afb213c780812a3df14c04d7f845

Modified Files
--------------
src/backend/utils/cache/plancache.c | 52 +++++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 9 deletions(-)

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 3 | next ›
Discussion Overview
grouppgsql-committers @
categoriespostgresql
postedAug 24, '13 at 7:14p
activeAug 24, '13 at 7:14p
posts3
users1
websitepostgresql.org...
irc#postgresql

1 user in discussion

Tom Lane: 3 posts

People

Translate

site design / logo © 2017 Grokbase