From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rysdam <drysdam(at)ll(dot)mit(dot)edu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Very slow queries on 8.1 |
Date: | 2005-11-17 16:28:35 |
Message-ID: | 26846.1132244915@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Rysdam <drysdam(at)ll(dot)mit(dot)edu> writes:
> Right now, I'm working on a test case that involves a table with ~360k
> rows called "nb.sigs". My sample query is:
> select * from nb.sigs where signum > 250000
> With no index, explain says this query costs 11341. After CREATE INDEX
> on the signum field, along with an ANALYZE for nb.sigs, the query costs
> 3456 and takes around 4 seconds to return the first row. This seems
> extremely slow to me, but I can't figure out what I might be doing
> wrong. Any ideas?
How many rows does that actually return, and what client interface are
you fetching it with? libpq, at least, likes to fetch the entire query
result before it gives it to you --- so you're talking about 4 sec to
get all the rows, not only the first one. That might be reasonable if
you're fetching 100k rows via an indexscan...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rysdam | 2005-11-17 16:28:42 | Re: Very slow queries on 8.1 |
Previous Message | Tom Lane | 2005-11-17 16:20:50 | Re: Numeric 508 datatype |