From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Tkach <dmitry(at)openratings(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query performance PLEASE HELP |
Date: | 2003-01-31 18:17:18 |
Message-ID: | 19603.1044037038@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
> Explain analyze says:
> Limit (cost=61.91..61.91 rows=1 width=192) (actual time=439435.47..439435.50 rows=10 loops=1)
> -> Sort (cost=61.91..61.91 rows=1 width=192) (actual time=439435.47..439435.48 rows=11 loops=1)
> -> Nested Loop (cost=0.00..61.90 rows=1 width=192) (actual time=7589.68..439423.75 rows=110 loops=1)
> -> Index Scan using managed_supplier_idx on managed_supplier ms (cost=0.00..22.02 rows=5 width=157) (actual time=6.72..3009.90 rows=14365 loops=1)
> -> Index Scan using tradestyle_duns_idx on tradestyle ts (cost=0.00..6.97 rows=1 width=35) (actual time=30.34..30.37 rows=0 loops=14365)
> Total runtime: 439436.45 msec
Judging from the tiny cost estimates, the planner thinks these tables
are tiny. Have you done a VACUUM ANALYZE lately?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Childs | 2003-01-31 18:17:55 | History |
Previous Message | Josh Berkus | 2003-01-31 17:34:28 | Re: One large v. many small |