Re: BUG #5255: COUNT(*) returns wrong result with LEFT JOIN

The following bug has been logged online:

Bug reference: 5255
Logged by: Matteo Beccati
Email address: php(at)beccati(dot)com
PostgreSQL version: 8.5alpha3
Operating system: NetBSD 5.0.1
Description: COUNT(*) returns wrong result with LEFT JOIN
Details:

Discovered this while fixing the php test suite to deal with 8.5 changes.

With the following data set a SELECT * query returns 1 rows, while SELECT
COUNT(*) returns 2.

CREATE TABLE a (id int PRIMARY KEY);
CREATE TABLE b (id int PRIMARY KEY, a_id int);
INSERT INTO a VALUES (0), (1);
INSERT INTO b VALUES (0, 0), (1, NULL);

test=# SELECT * FROM b LEFT JOIN a ON (b.a_id = a.id) WHERE (a.id IS NULL OR
a.id > 0);
id | a_id | id
----+------+----
1 | |
(1 row)

test=# SELECT COUNT(*) FROM b LEFT JOIN a ON (b.a_id = a.id) WHERE (a.id IS
NULL OR a.id > 0);
count
-------
2
(1 row)

"Matteo Beccati" <php(at)beccati(dot)com> writes:
> With the following data set a SELECT * query returns 1 rows, while SELECT
> COUNT(*) returns 2.

Hm, looks like the join-elimination patch is firing mistakenly. It's not
so much the count(*) that does it as the lack of any select-list
references to a:

regression=# explain SELECT * FROM b LEFT JOIN a ON (b.a_id = a.id) WHERE (a.id IS NULL OR a.id > 0);
QUERY PLAN
-----------------------------------------------------------------
Hash Left Join (cost=64.00..132.85 rows=720 width=12)
Hash Cond: (b.a_id = a.id)
Filter: ((a.id IS NULL) OR (a.id > 0))
-> Seq Scan on b (cost=0.00..31.40 rows=2140 width=8)
-> Hash (cost=34.00..34.00 rows=2400 width=4)
-> Seq Scan on a (cost=0.00..34.00 rows=2400 width=4)
(6 rows)

regression=# explain SELECT b.* FROM b LEFT JOIN a ON (b.a_id = a.id) WHERE (a.id IS NULL OR a.id > 0);
QUERY PLAN
-----------------------------------------------------
Seq Scan on b (cost=0.00..31.40 rows=2140 width=8)
(1 row)

I guess we missed something about when it's safe to do this optimization.

regards, tom lane

I wrote:
> I guess we missed something about when it's safe to do this optimization.

I've applied the attached patch to fix this.

regards, tom lane

Il 25/12/2009 18:13, Tom Lane ha scritto:
> I wrote:
>> I guess we missed something about when it's safe to do this optimization.
>
> I've applied the attached patch to fix this.

Thanks. Everything's working fine now!

Merry Xmas
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/