From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Bryan White" <bryan(at)arcamax(dot)com> |
Cc: | "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 16:49:36 |
Message-ID: | 23372.959273376@sss.pgh.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.
> It seems that with index scans the cursors start producing data right away
> (but the overall rate is slower). With sequential scan and sort the report
> gets no data for the first 30 minutes and then runs at about 4 times the
> rate of the index scan.
Right, that's what you'd expect: the sort has to be completed before it
knows which row to deliver first, but an indexscan has no such startup
cost.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-05-25 17:08:17 | Re: PG 7.0 is 2.5 times slower running a big report |
Previous Message | Tom Lane | 2000-05-25 16:32:40 | Re: Re: [ANNOUNCE] PostgreSQL 7.0 a success |