On Wed, Sep 22, 2010 at 9:36 AM, Ogden <lists@darkstatic.com> wrote:
>
> On Sep 21, 2010, at 2:34 PM, Ogden wrote:
>
>>
>> On Sep 21, 2010, at 2:16 PM, Greg Smith wrote:
>>
>>> Joshua D. Drake wrote:
>>>> PostgreSQL's defaults are based on extremely small and some would say
>>>> (non production) size databases. As a matter of course I always
>>>> recommend bringing seq_page_cost and random_page_cost more in line.
>>>>
>>>
>>> Also, they presume that not all of your data is going to be in memory, and the query optimizer needs to be careful
aboutwhat it does and doesn't pull from disk. If that's not the case, like here where there's 8GB of RAM and a 7GB
database,dramatic reductions to both seq_page_cost and random_page_cost can make sense. Don't be afraid to think
loweringbelow 1.0 is going too far--something more like 0.01 for sequential and 0.02 for random may actually reflect
realityhere.
>>>
>>
>> I have done just that, per your recommendations and now what took 14 seconds, only takes less than a second, so it
wascertainly these figures I messed around with. I have set:
>>
>> seq_page_cost = 0.01
>> random_page_cost = 0.02
>> cpu_tuple_cost = 0.01
>>
>> Everything seems to run faster now. I think this should be fine - I'll keep an eye on things over the next few days.
>>
>> I truly appreciate everyone's help.
>>
>> Ogden
>>
>
>
> I spoke too soon - well I came in this morning and reran the query that was speeded up yesterday by a lot after
tweakingthose numbers. This morning the first time I ran it, it took 16 seconds whereas every subsequent run was a
matterof 2 seconds. I assume there is OS caching going on for those results. Is this normal or could it also be the
speedof my disks which is causing a lag when I first run it (it's RAID 5 across 6 disks). Is there any explanation for
thisor what should those settings really be? Perhaps 0.01 is too low?
Yeah, I think those numbers are a bit low. Your database probably
isn't fully cached. Keep in mind there's going to be some fluctuation
as to what is and is not in cache, and you can't expect whatever plan
the planner picks to be exactly perfect for both cases. I might try
something more like 0.2 / 0.1. If you really need the query to be
fast, though, you might need to do more than jigger the page costs.
Did you try Tom's suggested rewrite?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
