> Stephan Szabo wrote:
> > On Tue, 21 Aug 2001, Joseph Shraibman wrote:
> >
> >
> >>Thank you, I was missing the parens.
> >>
> >>If I do an explain I see:
> >>
> >>-> Index Scan using m_u_and_p_key on m (cost=0.00..3035.22 rows=1363 width=12)
> >>
> >>
> >>even if I put a limit 1 on the select. Why is that?
> >>
> >
> > Is that the inner query (on the exists) or the entire explain?
>
> Just the inner query
>
> >
> > I guess it'd be useful to see the whole query and explain and maybe
> > schema.
>
> That's big and complicated. Can you reproduce this somewhere else?
I've only tried small data sets so nothing terribly meaningful.
>
> Here is the whole explain:
>
> 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 :)