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
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
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
"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
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
"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
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
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
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);
Hi,
I'm curious if there is a reason why "IS NOT DISTINCT FROM" is not an indexable
operation in a B-tree index, as it is effectively testing for equality albeit
with some "magic" for NULLs? Here is an example of what I mean, running tests
on 9.3.4:
-- create a table of integers
10 matches
Mail list logo
