Re: Planner constants for RAM resident databases
От | John A Meinel |
---|---|
Тема | Re: Planner constants for RAM resident databases |
Дата | |
Msg-id | 42C606AA.8060406@arbash-meinel.com обсуждение исходный текст |
Ответ на | Planner constants for RAM resident databases (Emil Briggs <emil@baymountain.com>) |
Ответы |
Re: Planner constants for RAM resident databases
|
Список | pgsql-performance |
Emil Briggs wrote: >>I just mentioned random_page_cost, but you should also tune >>effective_cache_size, since that is effectively most of your RAM. It >>depends what else is going on in the system, but setting it as high as >>say 12-14GB is probably reasonable if it is a dedicated machine. With >>random_page_cost 1.5-2, and higher effective_cache_size, you should be >>doing pretty well. >>John >>=:-> >> >> > >I tried playing around with these and they had no effect. It seems the only >thing that makes a difference is cpu_tuple_cost. > > > I'm surprised. I know cpu_tuple_cost can effect it as well, but usually the recommended way to get indexed scans is the above two parameters. When you do "explain analyze" of a query that you have difficulties with, how are the planner's estimates. Are the estimated number of rows about equal to the actual number of rows? If the planner is mis-estimating, there is a whole different set of tuning to do to help it estimate correctly. John =:-> PS> Use reply-all so that your comments go to the list.
Вложения
В списке pgsql-performance по дате отправления: