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 22:02:45 |
Message-ID: | CAKJS1f-w4RfFs_3A02p=1wb85JT8EuRNL6w=cjwkKFQT6-M=5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 4 Mar 2019 at 04:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> > 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.)
>
> > 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.
>
> No, what I'm thinking of is this bit in _bt_compare:
>
> result = DatumGetInt32(FunctionCall2Coll(&scankey->sk_func,
> scankey->sk_collation,
> datum,
> scankey->sk_argument));
>
> You absolutely will get errors during btree insertions and searches
> if a datatype's btree comparison functions ever return NULL (for
> non-NULL inputs).
I understand this is the case if an index happens to be used, but
there's no guarantee that's going to be the case. I was looking at the
case where an index was not used.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-03-03 22:06:05 | Re: NOT IN subquery optimization |
Previous Message | Tom Lane | 2019-03-03 21:58:17 | Re: Index-only scan is slower than Index scan. |