Re: Query performance PLEASE HELP

Tom Lane wrote:

>Dmitry Tkach <dmitry@openratings.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)
(actualtime=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.37rows=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?
>
Well... Yes. I am doing that daily. Actually, I was wonderring about
those estimates too, but that's not my primary concern right now -
perhaps, it should be, but, as far as I understand, the estimate only
matter for the query plan selection, and I don't have a problem with the
query plan - it seems fairly decent to me (as I said in the 'PS', the
other way around does make a little more sense to me, but it doesn't
seem to help much either)...

What I am primarily concerned about is the ACTUAL execution time - 30
milliseconds per row in that tradestyle table seems really excessive,
and 7 minutes total time just doesn't make any sense at all... Are you
saying this is the planner's problem? What do you think should the
correct plan look like then?

Thanks a lot!

Dima