Re: Huge speed penalty using <>TRUE instead of =FALSE
От | Greg Stark |
---|---|
Тема | Re: Huge speed penalty using <>TRUE instead of =FALSE |
Дата | |
Msg-id | FCA5FE46-3527-4068-987B-E07773818627@mit.edu обсуждение исходный текст |
Ответ на | Re: Huge speed penalty using <>TRUE instead of =FALSE (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
I don't think it even has to be so specific. We should just always rewrite bool <> bool into bool = NOT bool. Hmm. That only has a 50/50 chance of creating an indexable clause. Perhaps we could even rewrite it as "a = NOT b AND NOT a = b". -- Greg On 2009-07-17, at 3:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> ... But again, this is data type specific knowledge. > > Actually, now that I think about it, the planner already has > datatype-specific knowledge about boolean equality (see > simplify_boolean_equality). It would take just a few more lines of > code > there to recognize "x <> true" and "x <> false" as additional variant > spellings of the generic "x" or "NOT x" constructs. Not sure if it's > worth the trouble though; how many people really write such things? > > If you really wanted to take it to extremes, you could also reduce > cases like "x > false", but that's starting to get a bit silly. > > regards, tom lane > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: