| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | pgsql-bugs(at)postgresql(dot)org |
| Cc: | "Jan-Ivar Mellingen" <jan-ivar(dot)mellingen(at)alreg(dot)no> |
| Subject: | Re: Huge speed penalty using <>TRUE instead of =FALSE |
| Date: | 2009-07-17 10:36:44 |
| Message-ID: | 200907171336.44198.peter_e@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Friday 17 July 2009 11:12:41 Jan-Ivar Mellingen wrote:
> One of our customers discovered that by replacing <>TRUE with =FALSE in
> a query of a table containing 750.000 records reduced the query time
> from about 12 seconds to about 60 milliseconds!
> This is a dramatical difference, but I cannot understand why. In my head
> "<>TRUE" should behave exactly the same as "=FALSE". This looks like a
> bug to me, or am I overlooking something?
The planner just isn't that smart. The boolean type is a special case where
<> some_value implies = some_other_value, but this doesn't generalize well to
other data types. And the planner doesn't have a whole lot of data type
specific knowledge.
I think a better index definition might actually be on alarm_status, with a
partial index predicate on logg_avsluttet = false.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2009-07-17 12:35:29 | Re: Huge speed penalty using <>TRUE instead of =FALSE |
| Previous Message | handling numeric literals with dots in psql copy command | 2009-07-17 10:31:52 | BUG #4927: psql does "spoil" the query before sending it to server |