Re: Optimizer Doesn't Push Down Where Expressions on Rollups

From: Logan Bowers <logan(dot)bowers(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Optimizer Doesn't Push Down Where Expressions on Rollups
Date: 2020-03-11 16:58:11
Message-ID: 90491802-76A3-4AE8-AD2E-1646B68016FC@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Just in case it wasn’t obvious from the example, I’m talking about only cases where the all groups in the grouping set share a 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 set to 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Richard Guo <guofenglinux(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Demarest, Jamie 2020-03-11 18:24:45 Postgresql create a core while trying log a message to syslog
Previous Message Tom Lane 2020-03-11 14:06:43 Re: Optimizer Doesn't Push Down Where Expressions on Rollups

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2020-03-11 17:23:57 Re: Add A Glossary
Previous Message Corey Huinker 2020-03-11 16:56:55 Re: Add A Glossary