From: | Dave Crooke <dcrooke(at)gmail(dot)com> |
---|---|
To: | Kenneth Marshall <ktm(at)rice(dot)edu> |
Cc: | Anj Adu <fotographs(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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: | O/T: performance tuning cars |
Date: | 2010-06-11 15:58:11 |
Message-ID: | AANLkTilArnSa9GTzzi8O4nE5gT5jMA8HGAEmer-aRsbP@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Never say never with computer geeks ....
http://www.youtube.com/watch?v=mJyAA0oPAwE
On Fri, Jun 11, 2010 at 7:44 AM, Kenneth Marshall <ktm(at)rice(dot)edu> wrote:
> Hi Anj,
>
> That is an indication that your system was less correctly
> modeled with a random_page_cost=2 which means that the system
> will assume that random I/O is cheaper than it is and will
> choose plans based on that model. If this is not the case,
> the plan chosen will almost certainly be slower for any
> non-trivial query. You can put a 200mph speedometer in a
> VW bug but it will never go 200mph.
>
> Regards,
> Ken
>
> On Thu, Jun 10, 2010 at 07:54:01PM -0700, Anj Adu wrote:
> > 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
> > >>
> > >
> >
> > --
> > Sent via pgsql-performance mailing list (
> pgsql-performance(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-performance
> >
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | John Reeve | 2010-06-11 16:34:30 | Re: Large (almost 50%!) performance drop after upgrading to 8.4.4? |
Previous Message | Greg Smith | 2010-06-11 15:32:13 | Re: Query about index usage |