| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| 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:06:05 |
| Message-ID: | 5699.1551650765@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Mon, 4 Mar 2019 at 04:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
Not following your point? An index opclass is surely not going to be
designed on the assumption that it can never be used in an index.
Therefore, its support functions can't return NULL unless the index AM
allows that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2019-03-03 22:14:25 | Re: NOT IN subquery optimization |
| Previous Message | David Rowley | 2019-03-03 22:02:45 | Re: NOT IN subquery optimization |