Just in case it wasn’t obvious from the example, I’m talking about only cases where the all groups in the grouping set
sharea subset of columns in common and those are the columns being conditioned in the WHERE clause.
I get it if it’s not something actionable, but it is a bummer to see query time explode when going from one grouping
setto two grouping sets. :/
Cheers, and I’ve been a big fan of y’alls work for going on two decades now. Thank you!
> On Mar 11, 2020, at 7:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Richard Guo <guofenglinux@gmail.com> writes:
>> In your case, the WHERE clauses would get pushed down into the subquery
>> for both queries, with/without the ROLLUP. But since the subquery uses
>> grouping/grouping sets, the WHERE clauses would be put in HAVING of the
>> subquery.
>
> Right, we do successfully push the clauses into HAVING of the subquery.
>
>> Then when we plan for the subquery, we will decide whether a HAVING
>> clause can be transfered into WHERE. Usually we do not do that if there
>> are any nonempty grouping sets. Because if any referenced column isn't
>> present in all the grouping sets, moving such a clause into WHERE would
>> potentially change the results.
>
> Yeah. I think that it might be safe if the proposed clause can
> be proven strict for (some subset of?) the grouping columns, because
> that would eliminate the rollup grouping sets where those columns
> come out NULL because they aren't being grouped on. (This could then
> also factor into throwing away those grouping sets, perhaps.)
>
> Anyway, this is not a bug; it's a proposed planner improvement, and
> not a trivial one.
>
> regards, tom lane