From: | John A Meinel <john(at)arbash-meinel(dot)com> |
---|---|
To: | Yves Vindevogel <yves(dot)vindevogel(at)implements(dot)be> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Limit clause not using index |
Date: | 2005-06-21 15:14:24 |
Message-ID: | 42B82ED0.1010009@arbash-meinel.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Yves Vindevogel wrote:
> rvponp=# explain analyze select * from tblPrintjobs order by
> loginuser, desceventdate, desceventtime ;
> QUERY PLAN
> --------------------------------------------------------------------------------------------------------------------------------
>
> Sort (cost=345699.06..347256.49 rows=622972 width=203) (actual
> time=259438.952..268885.586 rows=622972 loops=1)
> Sort Key: loginuser, desceventdate, desceventtime
> -> Seq Scan on tblprintjobs (cost=0.00..25596.72 rows=622972
> width=203) (actual time=21.155..8713.810 rows=622972 loops=1)
> Total runtime: 271583.422 ms
> (4 rows)
Can you post it with the limit? I realize the query takes a long time,
but that is the more important query to look at.
Also, just as a test, if you can, try dropping most of the indexes
except for the important one. It might be that the planner is having a
hard time because there are too many permutations to try.
I believe if you drop the indexes inside a transaction, they will still
be there for other queries, and if you rollback instead of commit, you
won't lose anything.
BEGIN;
DROP INDEX ...
EXPLAIN ANALYZE SELECT *...
ROLLBACK;
John
=:->
From | Date | Subject | |
---|---|---|---|
Next Message | Yves Vindevogel | 2005-06-21 15:17:51 | Another question on indexes (drop and recreate) |
Previous Message | Yves Vindevogel | 2005-06-21 15:10:23 | Re: Limit clause not using index |