Re: Huge speed penalty using <>TRUE instead of =FALSE
От | Robert Haas |
---|---|
Тема | Re: Huge speed penalty using <>TRUE instead of =FALSE |
Дата | |
Msg-id | 603c8f070908100730x795fa9d2saf394fd327a10069@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Huge speed penalty using <>TRUE instead of =FALSE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Huge speed penalty using <>TRUE instead of =FALSE
|
Список | pgsql-bugs |
On Fri, Jul 17, 2009 at 10:21 AM, 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). =A0It 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. =A0Not sure if it's > worth the trouble though; how many people really write such things? I don't know, but there's probably somebody. I probably did it myself a few times, when I was just starting out. If it's easy, it seems worth doing. The problem with these things is that no matter how lame it seems to do whatever-it-is, the pain when someone does is really large... so adding a little bit of code to avoid that seems worthwhile, at least to me. > 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. Probably that one is beyond even my tolerance. ...Robert
В списке pgsql-bugs по дате отправления: