From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
Cc: | Vlad Arkhipov <arhipov(at)dc(dot)baikal(dot)ru>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Optimization idea |
Date: | 2010-04-23 13:36:40 |
Message-ID: | h2z603c8f071004230636zaec7edf2y2cbc0847ba17cd51@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Apr 23, 2010 at 9:09 AM, Cédric Villemain
<cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote:
> 2010/4/23 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov <arhipov(at)dc(dot)baikal(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-04-23 13:41:01 | Re: Optimization idea |
Previous Message | Cédric Villemain | 2010-04-23 13:09:34 | Re: Optimization idea |