Skip site navigation (1) Skip section navigation (2)

Re: Huge speed penalty using <>TRUE instead of =FALSE

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 (view raw or flat)
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.


In response to

pgsql-bugs by date

Next:From: Peter EisentrautDate: 2009-07-17 12:35:29
Subject: Re: Huge speed penalty using <>TRUE instead of =FALSE
Previous:From: handling numeric literals with dots in psql copy commandDate: 2009-07-17 10:31:52
Subject: BUG #4927: psql does "spoil" the query before sending it to server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group