From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: IS NOT DISTINCT FROM + Indexing |
Date: | 2014-07-23 17:30:36 |
Message-ID: | 20140723173036.GA5475@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> indexable, let alone used in a JOIN optimization. It could become a
> handy tool to simplify the SQL in queries that are returning a lot of
> NULL / NOT NULL data mixed together.
FWIW my project (abandoned for now, but I intend to get back to it
someday) to catalog NOT NULL constraints in pg_constraint had me
rewriting them into some kind of IS DISTINCT FROM NULL expression. (It
was IS NOT NULL initially until somebody pointed out that that wouldn't
work for composite type columns). I'm not sure how that interacts with
what you're doing here, maybe not at all; I thought I'd mention it.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kalai R | 2014-07-23 17:30:58 | Re: |
Previous Message | Emre Hasegeli | 2014-07-23 17:28:02 | Re: Index-only scans for multicolumn GIST |