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