aboutsummaryrefslogtreecommitdiff
path: root/src/backend/lib/binaryheap.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-08-24 15:14:21 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2013-08-24 15:14:21 -0400
commita5f11e24a4d1afb213c780812a3df14c04d7f845 (patch)
treecd4b6ec6e3ba4b3977f70eca992b255d892196a7 /src/backend/lib/binaryheap.c
parent3cf89057b5bced4478a285e0b49e321996b40044 (diff)
downloadpostgresql-a5f11e24a4d1afb213c780812a3df14c04d7f845.tar.gz
postgresql-a5f11e24a4d1afb213c780812a3df14c04d7f845.zip
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.
Diffstat (limited to 'src/backend/lib/binaryheap.c')
0 files changed, 0 insertions, 0 deletions