Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Andy Fan <zhihui.fan1213@gmail.com>, David Rowley <dgrowleyml@gmail.com>,
pavelsivash@gmail.com,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-08-21T20:49:07Z
Lists: pgsql-bugs
Attachments
- prevent-pushdown-with-grouping-sets.patch (text/x-diff) patch
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > subquery_planner isn't transferring HAVING clauses to WHERE if that > would cross a nontrivial GROUPING SETS. It could in theory do so by > inspecting whether the referenced columns are in all grouping sets or > none, but currently the planner doesn't have any reason to compute that > intersection and it would add quite a bit of complexity to that specific > point in the code. Hm. I see that computing that set is not really trivial. I'd supposed that we probably had code to do it somewhere, but if we don't, I'm disinclined to add it for this. So that leads to the conclusion that we should just shut off push-down in this situation, as per attached quick hack (no test case) patch. > In this example, pushing the condition below the aggregate would be > wrong anyway, no? Agreed. I hadn't thought hard enough about the semantics, but if "hundred" goes to null in a particular grouping set, so should "abs(hundred)". regards, tom lane
Commits
-
Avoid pushing quals down into sub-queries that have grouping sets.
- de627adaad3a 13.0 landed
- d3701bc8a25b 9.6.20 landed
- b439adcabbf9 11.10 landed
- 7edd36eae1fd 9.5.24 landed
- 6fa403e61241 10.15 landed
- 6b701eaaa90e 12.5 landed
- 4d346def1555 14.0 landed