Re: Enabling and disabling run time configuration parameters.

Поиск
Список
Период
Сортировка
Искать
От
Rod Taylor
Тема
Re: Enabling and disabling run time configuration parameters.
Дата
Msg-id
1054829663.7579.38.camel@jester
Ответ на
Список
Дерево обсуждения
Enabling and disabling run time configuration parameters. Yusuf <yusuf0478@netscape.net>
Re: Enabling and disabling run time configuration parameters. Rod Taylor <rbt@rbt.ca>
Re: Enabling and disabling run time configuration parameters. Josh Berkus <josh@agliodbs.com>
Re: Enabling and disabling run time configuration parameters. Bruno Wolff III <bruno@wolff.to>
Re: Enabling and disabling run time configuration parameters. Andrew Sullivan <andrew@libertyrms.info>
Re: Enabling and disabling run time configuration parameters. "scott.marlowe" <scott.marlowe@ihs.com>
> 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 

PGP Key: http://www.rbt.ca/rbtpub.asc
В списке pgsql-performance по дате отправления
От: Josh Berkus
Дата:
От: Bruno Wolff III
Дата:
FAQ