Re: Avoiding a seq scan on a table. - Mailing list pgsql-novice

From LWATCDR
Subject Re: Avoiding a seq scan on a table.
Date
Msg-id 8c38cea40801141131i28b300e8k24022fc808312233@mail.gmail.com
Whole thread Raw
In response to Re: Avoiding a seq scan on a table.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-novice
Are you saying that it should be = NULL and not is NULL?

SELECT COUNT(*) FROM rma where terminatedate is NULL; which is what is
in my code returns 254 rows and is the correct value.

When I changed it to SELECT COUNT(*) FROM rma where terminatedate = NULL
the select returns no rows.
So which one is correct?
I thought that is NULL was correct if not then what is the correct syntax?


On Jan 14, 2008 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> LWATCDR <lwatcdr@gmail.com> writes:
> > Anyway I put in the tree indexes and I am still getting a seq scan.
>
> > Aggregate  (cost=12.12..12.13 rows=1 width=0)
> >   ->  Result  (cost=0.00..12.12 rows=1 width=0)
> >         One-Time Filter: NULL::boolean
> >         ->  Seq Scan on issuetracking  (cost=0.00..12.12 rows=1 width=0)
> >               Filter: (((issue_target)::text = 'david'::text) OR
> > ((manager)::text = 'david'::text))
>
> You should worry about making the query correct before you worry about
> making it fast.  That constant false one-time filter is a red flag...
> looks like you forgot the difference between "IS NULL" and "= NULL".
>
>                         regards, tom lane
>

pgsql-novice by date:

Previous
From: Tom Lane
Date:
Subject: Re: Avoiding a seq scan on a table.
Next
From: "David Monarchi"
Date:
Subject: SQL state: 42P01