| From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Roman Fail <rfail(at)posportal(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: 7.3.1 New install, large queries are slow |
| Date: | 2003-01-16 17:47:02 |
| Message-ID: | 20030116094210.L6318-100000@megazone23.bigpanda.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, 16 Jan 2003, Josh Berkus wrote:
> Roman,
>
> > > Hey, Roman, how many records in BatchDetail, anyway?
> >
> > 23 million.
>
> And MSSQL is returning results in 3 seconds? I find that a bit hard
> to believe, unless this query is called repeatedly and that's the
> figure for the last call, where the records are being cached. I'll
> have to look at your hardware descriptions again.
>
> > It seems to me that the big, big isolated problem is the index scan
> > on batchdetail.tranamount.
>
> Nope. This was a misimpression caused by batchdetail waiting for a
> bunch of other processes to complete. Sometimes the parallelizing
> gives me a wrong impression of what's holding up the query. Sorry if I
> confused you.
I'm still not sure that it isn't a big part given that the time went down
by a factor of about 4 when index scans were disabled and a sequence scan
was done and that a sequence scan over the table with no other tables
joined looked to take about 5 minutes itself and the difference between
that seqscan and the big query was only about 20 seconds when
enable_indexscan was off unless I'm misreading those results.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2003-01-16 17:52:47 | Re: 7.3.1 New install, large queries are slow |
| Previous Message | Tom Lane | 2003-01-16 17:30:09 | Re: 7.3.1 New install, large queries are slow |