Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-23 Thread Alvaro Herrera
Jonathan S. Katz wrote: > Well that definitely answers "how hard would it be." - before > embarking on something laborious (as even just indexing is > nontrivial), I think it would be good to figure out how people are > using IS [NOT] DISTINCT FROM and if there is interest in having it be > indexa

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-23 Thread Kevin Grittner
Jonathan S. Katz wrote: > before embarking on something laborious (as even just indexing > is nontrivial), I think it would be good to figure out how people > are using IS [NOT] DISTINCT FROM and if there is interest in > having it be indexable, let alone used in a JOIN optimization. > It could b

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-22 Thread Jonathan S. Katz
On Jul 22, 2014, at 12:40 AM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> On Jul 21, 2014, at 9:51 PM, Tom Lane wrote: >>> The short reason why not is that it's not an operator (where "operator" >>> is defined as "something with a pg_operator entry"), and all our indexing >>> infrastructure

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-21 Thread Tom Lane
"Jonathan S. Katz" writes: > On Jul 21, 2014, at 9:51 PM, Tom Lane wrote: >> The short reason why not is that it's not an operator (where "operator" >> is defined as "something with a pg_operator entry"), and all our indexing >> infrastructure is built around the notion that indexable clauses are

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-21 Thread Jonathan S. Katz
On Jul 21, 2014, at 9:51 PM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an >> indexable operation in a B-tree index, > > The short reason why not is that it's not an operator (where "operator" > is defined as "something wit

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-21 Thread Tom Lane
"Jonathan S. Katz" writes: > I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an > indexable operation in a B-tree index, The short reason why not is that it's not an operator (where "operator" is defined as "something with a pg_operator entry"), and all our indexing infrastruct

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-21 Thread Peter Geoghegan
On Mon, Jul 21, 2014 at 4:57 PM, Andres Freund wrote: > I rather doubt it will. x in (y1, ... yn) is essentially expanded to x = > y1 OR x = y2, ... OR x = yn. I.e. the NULL comparison will be done using > normal equality comparison and thus not return a row with a NULL > orderid. Am I missing som

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-21 Thread Andres Freund
On 2014-07-21 16:51:32 -0700, Peter Geoghegan wrote: > On Mon, Jul 21, 2014 at 4:16 PM, Jonathan S. Katz > wrote: > > With NULLs being indexable, I was wondering if there was some reason why IS > > NOT DISTINCT FROM could not use the index? > > FWIW this works: > > postgres=# explain analyze se

Re: [HACKERS] IS NOT DISTINCT FROM + Indexing

2014-07-21 Thread Peter Geoghegan
On Mon, Jul 21, 2014 at 4:16 PM, Jonathan S. Katz wrote: > With NULLs being indexable, I was wondering if there was some reason why IS > NOT DISTINCT FROM could not use the index? FWIW this works: postgres=# explain analyze select * from orders where orderid in (5, null);