From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Li, Zheng" <zhelli(at)amazon(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Richard Guo <riguo(at)pivotal(dot)io>, "Finnerty, Jim" <jfinnert(at)amazon(dot)com> |
Subject: | Re: NOT IN subquery optimization |
Date: | 2019-03-03 13:34:42 |
Message-ID: | CAKJS1f8d7AJn3TRLfyHVGAEFJAZYmSONFtQkTtF5bvyLevso2w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
not_in_anti_join_v1.3.patch | application/octet-stream | 50.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2019-03-03 13:41:29 | Re: Making all nbtree entries unique by having heap TIDs participate in comparisons |
Previous Message | Michael Banck | 2019-03-03 10:51:48 | Re: Online verification of checksums |