Re: Using IN with subselect

Dave Smith <dave(dot)smith(at)candata(dot)com> writes:

> That's what I wanted it to do I just did not understand how to read the
> explain. So is it HashAggregate that means this already loaded?

The HashAggregate Node is doing a GROUP BY command. (or the implicit GROUP BY
if you used an aggregate function without one.)

The "Hash IN Join" is a particular type of join that behaves the way Tom
describes. Each type of join behaves differently. A Nested Loop join would
execute one side once and the other many times. A Merge join executes both
sides once.

You could also run "explain analyze" instead of just "explain" and look at the
"loops" number that would tell you how many times the node actually was
executed.

> > Dave Smith <dave(dot)smith(at)candata(dot)com> writes:
> > > Well here is explain. I would guess that it is executed each time ..
> > > function any different?
> >
> > > HashAggregate (cost=288.32..288.32 rows=1 width=32)
> > > -> Hash IN Join (cost=288.18..288.31 rows=1 width=32)
> > > -> Subquery Scan journal_all (cost=282.36..282.45 rows=2 width=64)
> > > -> Hash (cost=5.83..5.83 rows=1 width=13)
> > > -> Index Scan using glmast_index3 on glmast (cost=0.00..5.83 rows=1 width=13)
> >
> > No ... this plan says to scan glmast once, load the selected rows into
> > an in-memory hash table, then scan journal_all once and probe the hash
> > table for matches. It looks like a pretty decent choice of plan to me.

--
greg