Re: BUG #9007: List comparison

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: stefan(dot)kirchev(at)gmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #9007: List comparison
Date: 2014-01-28 13:59:04
Message-ID: CABRT9RD8pqROHBMtUj940HcoFjW5ghVzCSL5aWELH4STxPRwJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jan 28, 2014 at 10:56 AM, <stefan(dot)kirchev(at)gmail(dot)com> wrote:
> select * from table1 where (c1, c2) not in (select c1, c2 from table2);

Note that if there are any (NULL, NULL) values in table2 then NOT IN
*always* returns zero results. This counter-intuitive behavior is
mandated by the SQL specification and also makes the NOT IN clause
hard to optimize. It's not a bug, however.

It's almost always faster and more foolproof to convert them to NOT
EXISTS clauses like this:
select * from table1 where not exists
(select * from table2 where (table1.c1, table1.c2) = (table2.c1,
table2.c2));

db=# create table table1 (c1, c2) as values (1, 1);
db=# create table table2 (c1, c2) as values (2, 2);
db=# select * from table1 where (c1, c2) not in (select c1, c2 from table2);
c1 | c2
----+----
1 | 1
(1 row)

db=# insert into table2 values(null, null);
db=# select * from table1 where (c1, c2) not in (select c1, c2 from table2);
c1 | c2
----+----
(0 rows)

db=# select * from table1 where not exists (select * from table2 where
(table1.c1, table1.c2) = (table2.c1, table2.c2));
c1 | c2
----+----
1 | 1
(1 row)

> Is that a buffers size issue?

No, tuning parameters should never affect the correctness of returned
results, only time.

Regards,
Marti

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Paul Morie 2014-01-28 15:41:49 Re: BUG #9003: Hard-coding to localhost in postmaster
Previous Message stefan.kirchev 2014-01-28 08:56:34 BUG #9007: List comparison