Re: PG 7.0 is 2.5 times slower running a big report

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bryan White <bryan(at)arcamax(dot)com>, Jesse Estevez <jestevez(at)travel-italy(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: PG 7.0 is 2.5 times slower running a big report
Date: 2000-05-25 17:08:17
Message-ID: 200005251708.NAA27559@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> "Bryan White" <bryan(at)arcamax(dot)com> writes:
> > I have recoverd the performance lost when I moved to Postgres 7.0 by
> > executing SET enable_indexscan = OFF before creating my cursors and
> > turning it back on for the inner loop query. It may even be faster
> > then before so I am happy.
>
> OK, so it was the indexscans that were hurting. (7.0 has new sorting
> code too, so I was a little afraid that the problem might be with the
> sorts. Evidently not.)
>
> This suggests that at least on your setup, the default value of 4.0 for
> random_page_cost might still be too low. I have not tried to measure
> that number on a Linux machine, just on machines with BSD-derived
> filesystems. Maybe Linux does a lot worse with random accesses than
> BSD? Needs looking into.

As I remember, Linux turns off file system prefetch if a seek is done.
BSD file systems turn off prefetch only if prefetched blocks remain
unused.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ari Jolma 2000-05-25 18:24:28 Re: problem with NOTICE: _outNode: don't know how to print type
Previous Message Tom Lane 2000-05-25 16:49:36 Re: PG 7.0 is 2.5 times slower running a big report