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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: logan(dot)bowers(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimizer Doesn't Push Down Where Expressions on Rollups
Date: 2020-03-19 09:28:19
Message-ID: CAMbWs4_Bt=b-xQOU4iMjSpLnGy7N3Osv47MEMmrzzbV8RTaLkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hi,

(cc'ing -hackers)

We used to push down clauses from HAVING to WHERE when grouping sets are
used in 61444bfb and then reverted it in a6897efa because of wrong
results issue. As now there are people suffering from performance issue
as described in [1], I'm wondering if we should give it another try.

[1]
https://www.postgresql.org/message-id/flat/17F738BE-8D45-422C-BAD0-ACA3090BF46D%40gmail.com

Thanks
Richard

On Thu, Mar 12, 2020 at 6:22 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:

> On Wed, Mar 11, 2020 at 10:06 PM 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.)
>>
>
> This seems correct to me. If we can prove the HAVING clause is strict
> for some grouping columns, then we can throw away the grouping sets that
> do not contain these grouping columns, since their results would be
> eliminated by this HAVING clause. After that we can move this HAVING
> clause to WHERE. I'm thinking about this example:
>
> select c1, c2, sum(c4) from t group by
> grouping sets ((c1, c2), (c2, c3), (c1, c4)) having c2 = 2;
>
> select c1, c2, sum(c4) from t group by
> grouping sets ((c1, c2), (c2, c3)) having c2 = 2;
>
> select c1, c2, sum(c4) from t where c2 = 2 group by
> grouping sets ((c1, c2), (c2, c3));
>
>
> For non-strict HAVING clause, if its referenced columns are present in
> all the grouping sets, I think we should also be able to move it to
> WHERE.
>
> Thanks
> Richard
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2020-03-19 11:04:21 Re: BUG #16302: too many range table entries - when count partition table(65538 childs)
Previous Message Sandeep Thakkar 2020-03-19 09:16:06 Re: windows 10 postgres install bug

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-03-19 09:32:57 Re: Internal key management system
Previous Message David Rowley 2020-03-19 08:52:11 Re: Berserk Autovacuum (let's save next Mandrill)