Re: Using each rel as both outer and inner for JOIN_ANTI

Richard Guo <guofenglinux@gmail.com> writes:
> [ v4-0001-Using-each-rel-as-both-outer-and-inner-for-anti-j.patch ]

I took a quick look through this.  The executor changes are indeed
impressively short, but that's largely because you've paid zero
attention to updating obsoleted comments.  For example, in
nodeHashjoin.c there are lots of references to right/full joins
that likely now need to cover right-anti.  I'm not sure that the
empty-rel startup optimizations are correct for this case, either.

I don't have a warm feeling about the planner changes being correct:
it looks like what you mostly did was to treat JOIN_RIGHT_ANTI
identically to JOIN_ANTI everywhere, which is surely wrong.
As an example of this, optimizer/README mentions

  Similarly, parameterized paths do not normally get preference in add_path
  for having cheap startup cost; that's seldom of much value when on the
  inside of a nestloop, so it seems not worth keeping extra paths solely for
  that.  An exception occurs for parameterized paths for the RHS relation of
  a SEMI or ANTI join: in those cases, we can stop the inner scan after the
  first match, so it's primarily startup not total cost that we care about.

For RIGHT_ANTI it'd become startup of the outer scan that counts, but
I don't think you've gotten that right here.

There are various references to JOIN_ANTI in planner peripheral code,
e.g. selfuncs.c, that probably need adjustment.

[ wanders away wondering if JOIN_RIGHT_SEMI should become a thing ... ]

            regards, tom lane