Re: BUG #1528: Rows returned that should be excluded by WHERE clause

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Peter Wright" <pete(at)flooble(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1528: Rows returned that should be excluded by WHERE clause
Date: 2005-03-08 08:07:13
Message-ID: 4017.1110269233@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

"Peter Wright" <pete(at)flooble(dot)net> writes:
> Description: Rows returned that should be excluded by WHERE clause

Interesting point. The view and union don't seem to be the issue;
I think the problem can be expressed as

regression=# select 2 as id, max(b) from t2 having 2 = 1;
id | max
----+-----
2 |
(1 row)

Now, if this were a WHERE clause, I think the answer would be right:

regression=# select 2 as id, max(b) from t2 where 2 = 1;
id | max
----+-----
2 |
(1 row)

but since it's HAVING I think this is probably wrong. Looking at the
EXPLAIN output

regression=# explain select 2 as id, max(b) from t2 having 2 = 1;
QUERY PLAN
----------------------------------------------------------------
Aggregate (cost=3.68..3.68 rows=1 width=2)
-> Result (cost=0.00..3.14 rows=214 width=2)
One-Time Filter: false
-> Seq Scan on t2 (cost=0.00..3.14 rows=214 width=2)
(4 rows)

the issue is clearly that the known-false HAVING clause is pushed down
inside the aggregation, as though it were WHERE. The existing code
pushes down HAVING to WHERE if the clause contains no aggregates, but
evidently this is too simplistic. What are the correct conditions for
pushing down HAVING clauses to WHERE?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Avram 2005-03-08 08:55:45 BUG #1530: search on uuid indexed article returns no resultat
Previous Message Daniel Wilches 2005-03-07 23:57:26 BUG #1529: Psql doesnt ask for passowrd

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2005-03-08 08:25:46 Re: Best practices: MERGE
Previous Message Tom Lane 2005-03-08 07:21:18 Re: Continue transactions after errors in psql