Re: NOT IN subquery optimization

On Sun, 3 Mar 2019 at 17:11, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (At the code level, this is implicit in the fact that the comparison
> function will be called via FunctionCall2Coll or a sibling, and those
> all throw an error if the called function returns NULL.)
>
> Now, it doesn't say in so many words that the comparison operators
> have to yield results consistent with the comparison support function,
> but I think that's pretty obvious ...

Ah okay. I can get it to misbehave by setting fcinfo->isnull = true in
the debugger from int4eq(). I see the NULL result there is not
verified as that's just translated into "false" by ExecInterpExpr()'s
EEOP_QUAL case. If you're saying something doing that is
fundamentally broken, then I guess we're okay.

> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> > The list of builtin types that have a hash opfamily but no btree
> > opfamily that support NOT IN are not very exciting, so doing the same
> > for hash might not be worth the extra code.
>
> Agreed for builtin types, but there might be some extensions out there
> where this doesn't hold. It's not terribly hard to imagine a data type
> that hasn't got a linear sort order but is amenable to hashing.

On reflection, it seems pretty easy to add this check, so I've done so
in the attached.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services