> My plan is for every query that could be optimized by adjusting
> parameters: I'll enable parameters that'll speed it up, run the query,
> then set the parameters back to their default values.
Unless you intend to regularly test these, or have static data this may
cause you more problems than it fixes.
Any change in the data may make the plan you have forced a non-optimal
one.
A much better approach is to tweek the cost values that cause the
planner to chose that particular plan. The random_page_cost will
probably have the most effect on the plan chosen.
#effective_cache_size = 1000 # typically 8KB each
#random_page_cost = 4 # units are one sequential page fetch
cost
#cpu_tuple_cost = 0.01 # (same)
#cpu_index_tuple_cost = 0.001 # (same)
#cpu_operator_cost = 0.0025 # (same)
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc