Stephan Szabo wrote:
>>Limit (cost=48.39..48.39 rows=1 width=70)
>> -> Sort (cost=48.39..48.39 rows=2 width=70)
>> -> Hash Join (cost=18.46..48.38 rows=2 width=70)
>> -> Index Scan using u_p_key on u (cost=0.00..27.66 rows=48 width=28)
>> -> Hash (cost=18.39..18.39 rows=28 width=42)
>> -> Seq Scan on d (cost=0.00..18.39 rows=28 width=42)
>> SubPlan
>> -> Nested Loop (cost=0.00..4.04 rows=1 width=20)
>> -> Index Scan using a_pkey on a (cost=0.00..2.01 rows=1 width=4)
>> -> Index Scan using p_pkey on pu (cost=0.00..2.02 rows=1 width=16)
>> -> Index Scan using m_u_and_p_key on m (cost=0.00..3035.22 rows=1363
>>width=44)
>>
>
> At least, what was the query that generated this and is it running
> slowly or otherwise giving problems? The total explain doesn't seem
> unreasonable to my relatively untrained eyes in the absense of knowing the
> query :)
>
Well the total cost should be at least as big as the sub-costs, no? Doesn't that seem
strange?
--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio. http://www.targabot.com