On Mon, Aug 10, 2009 at 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote:
>>> Actually, now that I think about it, the planner already has
>>> datatype-specific knowledge about boolean equality (see
>>> simplify_boolean_equality). It would take j
Robert Haas writes:
> On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote:
>> 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 <>
On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote:
> Peter Eisentraut 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 ta
Jan-Ivar Mellingen skrev:
> 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!
>
> The problematic query looks like this:
> SELECT * FROM AlarmLogg WHERE L
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 wro
Peter Eisentraut 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 <> tr
Jan-Ivar Mellingen writes:
> 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 not a bug. The set of operators that are indexable is well
documen
On Friday 17 July 2009 12:45:47 Mikael Krantz wrote:
> It might be that your column may be NULL as well as TRUE or FALSE. I
> am no expert in this matter though.
Nulls also need to be considered when attempting to substitute purportedly
equivalent clauses. But in this case it wouldn't actually m
It might be that your column may be NULL as well as TRUE or FALSE. I
am no expert in this matter though.
/M
On Fri, Jul 17, 2009 at 10:12 AM, 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
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 cann
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!
The problematic query looks like this:
SELECT * FROM AlarmLogg WHERE Logg_avsluttet <> TRUE AND
Alarm_status=
11 matches
Mail list logo
