From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Allen Landsidel <alandsidel(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Strange (?) Index behavior? |
Date: | 2004-11-11 20:49:46 |
Message-ID: | 873bzgdsb9.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Allen Landsidel <alandsidel(at)gmail(dot)com> writes:
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------------------
> Index Scan using sname_unique on "testtable" (cost=0.00..34453.74
> rows=8620 width=20) (actual time=77.004..537065.079 rows=74612
> loops=1)
> Index Cond: ((sname >= 'AA'::text) AND (sname < 'AB'::text))
> Filter: (sname ~~ 'AA%'::text)
> Total runtime: 537477.737 ms
> (4 rows)
>
> Time: 537480.571 ms
Nothing you're going to do to the query is going to come up with a more
effective plan than this. It's using the index after all. It's never going to
be lightning fast because it has to process 75k rows.
However 75k rows shouldn't be taking nearly 10 minutes. It should be taking
about 10 seconds.
The 77ms before finding the first record is a bit suspicious. Have you
vacuumed this table regularly? Try a VACUUM FULL VERBOSE, and send the
results. You might try to REINDEX it as well, though I doubt that would help.
Actually you might consider clustering the table on sname_unique. That would
accomplish the same thing as the VACUUM FULL command and also speed up the
index scan. And the optimizer knows (if you analyze afterwards) it so it
should be more likely to pick the index scan. But currently you have to rerun
cluster periodically.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Edwin Eyan Moragas | 2004-11-11 21:10:57 | Re: How to speed-up inserts with jdbc |
Previous Message | Allen Landsidel | 2004-11-11 19:30:57 | Re: Strange (?) Index behavior? |