| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Lucas Nussbaum <lucas(at)lucas-nussbaum(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14608: no index scan with NOT IN and ENUM |
| Date: | 2017-04-01 17:57:33 |
| Message-ID: | CAKFQuwZAJ=d+AqxAM0vXG48b1WNJPff=ioAiyHNb0scwC5XkcA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sat, Apr 1, 2017 at 10:16 AM, Lucas Nussbaum <lucas(at)lucas-nussbaum(dot)net>
wrote:
> Note, though, that such reasoning is done for boolean values. For
> example, "b <> false" seems to be converted to "b = true" if that makes
> it possible to use an index. But I also see how simplifying boolean
> expressions makes more sense than rewriting ENUM-based expressions.
>
In particular one doesn't need a system catalog to know the possible
values of boolean and being only two never changing options there is an
implicit immutable negator function.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-04-02 15:58:57 | Re: could not fork autovacuum worker process: No error |
| Previous Message | Lucas Nussbaum | 2017-04-01 17:16:14 | Re: BUG #14608: no index scan with NOT IN and ENUM |