Re: Fixing Grittner's planner issues

On Wed, Feb 11, 2009 at 8:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [ forgot to respond to this earlier, sorry ]

Thanks for responding now.

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On a related note, I have some vague unease about planning A SEMI JOIN
>> B as A INNER JOIN (UNIQUE B), as make_one_rel currently attempts to
>> do. For a merge join or nested loop, I don't see how this can ever be
>> a win over teaching the executor to just not rescan B. For a hash
>> join, it can be a win if B turns out to have duplicates, but then
>> again you could also just teach the executor to skip the insertion of
>> the duplicate into the table in the first place (it has to hash 'em
>> anyway...). I think maybe I'm not understanding something about the
>> logic here.
>
> The case where this is a win is where B is small (say a few rows) and
> not unique, and A is large, and there's a relevant index on A. Then
> considering this join approach lets us produce a plan that looks like
>
> NestLoop
> HashAggregate (or GroupAggregate)
> Scan B
> IndexScan A
> Index Condition : A.x = B.y

Right, so maybe I wasn't as clear as I could have been in asking the
question. I do understand how it can be a win to unique B and use it
as the OUTER relation (jointype JOIN_UNIQUE_OUTER). What I don't
understand is how it can ever be a win to unique B and use it as the
INNER relation (jointype JOIN_UNIQUE_INNER).

>> One thing I notice is that src/backend/optimizer/README should
>> probably be updated with the rules for commuting SEMI and ANTI joins;
>> it currently only mentions INNER, LEFT, RIGHT, and FULL.
>
> Yeah, I noticed that too. How embarrassing. Will fix it as part of
> the patch, which I hope to start on tomorrow.

Cool. On the topic of documentation, I find the following comment in
joinrels.c rather impenetrable:

/*
* Do these steps only if we actually have a
regular semijoin,
* as opposed to a case where we should
unique-ify the RHS.
*/

I don't think "regular semijoin" is a term of art, so I'm somewhat at
a loss to understand what this means. And why "as opposed to" a case
where we should unique-ify the RHS? ISTM the code will sometimes try
both...

...Robert