Re: 8.2.4 serious slowdown

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Sim Zacks" <sim(at)compulab(dot)co(dot)il>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 8.2.4 serious slowdown
Date: 2008-01-11 09:54:40
Message-ID: 162867790801110154k568072b0k8434d8bf339fa1ec@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hello

On 11/01/2008, Sim Zacks <sim(at)compulab(dot)co(dot)il> wrote:
> I changed it to "where f.commited is not true" and the query now takes 1 second as opposed to 60.
> (much faster then the 3 seconds it took on 8.0.1, which could also be because of the coalesce there)
> Is it considered better practice (or more efficient) to always use (x is not or x=value)
> instead of coalesce? Or does it make more sense to turn on the option "transform_null_equals"?
>

You can use without coalesce() = some operator IS DISTINCT FROM ... .
Use coalesce only if you need some NON NULL value.

for you sample

where f.commited IS DISTINCT FROM true;

operator IS DISTINCT FROM is NULL insensitive

Regards
Pavel Stehule

> Thank you much
> Sim
>
> > I assume that the original query is something along the lines of
> >
> > d left join f on (...) where coalesce(f.commited, false) = false
> >
> >
> > In the meantime, Sim would probably have better luck if he restructured
> > this particular clause in some other way, say
> >
> > where f.commited is not true
> > or
> > where f.commited = false or f.commited is null
> >
> > Note also that he really ought to move up to 8.2.6, as 8.2.4 is not
> > very sane about what IS NULL means for a left join's result.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message alphax 2008-01-11 13:49:20 How to safely compare transaction id?
Previous Message Richard Huxton 2008-01-11 08:46:37 Re: phpPgAdmin-4.1.3 login fail

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-01-11 10:25:40 Storage Model for Partitioning
Previous Message Simon Riggs 2008-01-11 09:42:59 Re: Dynamic Partitioning using Segment Visibility Maps