Re: Optimization idea
От | Robert Haas |
---|---|
Тема | Re: Optimization idea |
Дата | |
Msg-id | h2z603c8f071004230636zaec7edf2y2cbc0847ba17cd51@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Optimization idea (Cédric Villemain <cedric.villemain.debian@gmail.com>) |
Ответы |
Re: Optimization idea
|
Список | pgsql-performance |
On Fri, Apr 23, 2010 at 9:09 AM, Cédric Villemain <cedric.villemain.debian@gmail.com> wrote: > 2010/4/23 Robert Haas <robertmhaas@gmail.com>: >> On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov <arhipov@dc.baikal.ru> wrote: >>> I don't think this is just an issue with statistics, because the same >>> problem arises when I try executing a query like this: >> >> I'm not sure how you think this proves that it isn't a problem with >> statistics, but I think what you should be focusing on here, looking >> back to your original email, is that the plans that are actually much >> faster have almost as much estimated cost as the slower one. Since >> all your data is probably fully cached, at a first cut, I might try >> setting random_page_cost and seq_page_cost to 0.005 or so, and >> adjusting effective_cache_size to something appropriate. > > that will help worrect the situation, but the planner is loosing here I think. Well, what do you think the planner should do differently? ...Robert
В списке pgsql-performance по дате отправления: