From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c) |
Date: | 2020-09-17 20:09:51 |
Message-ID: | 20200917200951.pfjgiit4ygjvmmen@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 17, 2020 at 02:12:12PM -0300, Ranier Vilela wrote:
>Hi,
>
>In case gd->any_hashable is FALSE, grouping_is_hashable is never called.
>In this case, the planner could use HASH for groupings, but will never know.
>
The condition is pretty simple - if the query has grouping sets, look at
grouping sets, otherwise look at groupClause. For this to be an issue
the query would need to have both grouping sets and (independent) group
clause - which AFAIK is not possible.
For hashing to be worth considering, at least one grouping set has to be
hashable - otherwise it's pointless.
Granted, you could have something like
GROUP BY GROUPING SETS ((a), (b)), c
which I think essentially says "add c to every grouping set" and that
will be covered by the any_hashable check.
Or how would a query triggering this look like?
>Apparently gd pointer, will never be NULL there, verified with Assert(gd !=
>NULL).
>
Um, what? If you add the assert right before the if condition, you won't
even be able to do initdb. It's pretty clear it'll crash for any query
without grouping sets.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-09-17 20:19:05 | Re: factorial function/phase out postfix operators? |
Previous Message | Tomas Vondra | 2020-09-17 19:19:18 | Re: WIP: BRIN multi-range indexes |