From: | Anj Adu <fotographs(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andy Colson <andy(at)squeakycode(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: slow query performance |
Date: | 2010-06-11 02:54:01 |
Message-ID: | AANLkTikuvlQCq2FUyOPYfmh_A2by39rMsIB3vDRCbaUk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I changed random_page_cost=4 (earlier 2) and the performance issue is gone
I am not clear why a page_cost of 2 on really fast disks would perform badly.
Thank you for all your help and time.
On Thu, Jun 10, 2010 at 8:32 AM, Anj Adu <fotographs(at)gmail(dot)com> wrote:
> Attached
>
> Thank you
>
>
> On Thu, Jun 10, 2010 at 6:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Jun 9, 2010 at 11:17 PM, Anj Adu <fotographs(at)gmail(dot)com> wrote:
>>> The plan is unaltered . There is a separate index on theDate as well
>>> as one on node_id
>>>
>>> I have not specifically disabled sequential scans.
>>
>> Please do "SHOW ALL" and attach the results as a text file.
>>
>>> This query performs much better on 8.1.9 on a similar sized
>>> table.(althought the random_page_cost=4 on 8.1.9 and 2 on 8.4.0 )
>>
>> Well that could certainly matter...
>>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise Postgres Company
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | David Jarvis | 2010-06-11 02:56:35 | Re: Analysis Function |
Previous Message | Andy Colson | 2010-06-11 02:11:10 | Re: Analysis Function |