Thread: Missing docs for new enable_group_by_reordering GUC
This commit added enable_group_by_reordering:
commit 0452b461bc4
Author: Alexander Korotkov <akorotkov@postgresql.org>
Date: Sun Jan 21 22:21:36 2024 +0200
Explore alternative orderings of group-by pathkeys during optimization.
When evaluating a query with a multi-column GROUP BY clause, we can minimize
sort operations or avoid them if we synchronize the order of GROUP BY clauses
with the ORDER BY sort clause or sort order, which comes from the underlying
query tree. Grouping does not imply any ordering, so we can compare
the keys in arbitrary order, and a Hash Agg leverages this. But for Group Agg,
we simply compared keys in the order specified in the query. This commit
explores alternative ordering of the keys, trying to find a cheaper one.
The ordering of group keys may interact with other parts of the query, some of
which may not be known while planning the grouping. For example, there may be
an explicit ORDER BY clause or some other ordering-dependent operation higher up
in the query, and using the same ordering may allow using either incremental
sort or even eliminating the sort entirely.
The patch always keeps the ordering specified in the query, assuming the user
might have additional insights.
This introduces a new GUC enable_group_by_reordering so that the optimization
may be disabled if needed.
Discussion: https://postgr.es/m/7c79e6a5-8597-74e8-0671-1c39d124c9d6%40sigaev.ru
Author: Andrei Lepikhov, Teodor Sigaev
Reviewed-by: Tomas Vondra, Claudio Freire, Gavin Flower, Dmitry Dolgov
Reviewed-by: Robert Haas, Pavel Borisov, David Rowley, Zhihong Yu
Reviewed-by: Tom Lane, Alexander Korotkov, Richard Guo, Alena Rybakina
It mentions it was added as a GUC to postgresql.conf, but I see no SGML
docs for this new GUC value. Would someone please add docs for this?
Thanks.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On 6/18/24 09:32, Bruce Momjian wrote: > This commit added enable_group_by_reordering: > > commit 0452b461bc4 > Author: Alexander Korotkov <akorotkov@postgresql.org> > Date: Sun Jan 21 22:21:36 2024 +0200 > It mentions it was added as a GUC to postgresql.conf, but I see no SGML > docs for this new GUC value. Would someone please add docs for this? > Thanks. It is my mistake, sorry for that. See the patch in attachment. -- regards, Andrei Lepikhov
Attachment
On Tue, Jun 18, 2024 at 9:14 AM Andrei Lepikhov <lepihov@gmail.com> wrote: > On 6/18/24 09:32, Bruce Momjian wrote: > > This commit added enable_group_by_reordering: > > > > commit 0452b461bc4 > > Author: Alexander Korotkov <akorotkov@postgresql.org> > > Date: Sun Jan 21 22:21:36 2024 +0200 > > It mentions it was added as a GUC to postgresql.conf, but I see no SGML > > docs for this new GUC value. Would someone please add docs for this? > > Thanks. > It is my mistake, sorry for that. See the patch in attachment. Bruce, thank for noticing. Andrei, thank you for providing a fix. Please, check the revised patch. ------ Regards, Alexander Korotkov Supabase
Attachment
Hi, Alexander!
On Tue, 18 Jun 2024 at 16:13, Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Tue, Jun 18, 2024 at 9:14 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
> On 6/18/24 09:32, Bruce Momjian wrote:
> > This commit added enable_group_by_reordering:
> >
> > commit 0452b461bc4
> > Author: Alexander Korotkov <akorotkov@postgresql.org>
> > Date: Sun Jan 21 22:21:36 2024 +0200
> > It mentions it was added as a GUC to postgresql.conf, but I see no SGML
> > docs for this new GUC value. Would someone please add docs for this?
> > Thanks.
> It is my mistake, sorry for that. See the patch in attachment.
Bruce, thank for noticing. Andrei, thank you for providing a fix.
Please, check the revised patch.
I briefly looked into this docs patch. Planner gucs are arranged alphabetically, so enable_group_by_reordering is better to come after enable-gathermerge not before.
+ Enables or disables the reordering of keys in a
+ <literal>GROUP BY</literal> clause to match the ordering keys of a+ child node of the plan, such as an index scan. When turned off, keys
+ in a <literal>GROUP BY</literal> clause are only reordered to match
+ the <literal>ORDER BY</literal> clause, if any. The default is
+ <literal>on</literal>.
I'd also suggest the same style as already exists for enable_presorted_aggregate guc i.e:
the <literal>ORDER BY</literal> clause, if any. When enabled, the planner will try to produce a more efficient plan. The default value is on.
Regards,
Pavel Borisov
Supabase
Controls if the query planner will produce a plan which will provide <literal>GROUP BY</literal> keys presorted in the order of keys of a child node of the plan, such as an index scan. When disabled, the query planner will produce a plan with <literal>GROUP BY</literal> keys only reordered to matchthe <literal>ORDER BY</literal> clause, if any. When enabled, the planner will try to produce a more efficient plan. The default value is on.
A correction of myself: presorted -> sorted, reordered ->sorted
Regards,
Pavel
On Tue, Jun 18, 2024 at 4:14 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote: >> Controls if the query planner will produce a plan which will provide <literal>GROUP BY</literal> keys presorted in theorder of keys of a child node of the plan, such as an index scan. When disabled, the query planner will produce a planwith <literal>GROUP BY</literal> keys only reordered to match >> the <literal>ORDER BY</literal> clause, if any. When enabled, the planner will try to produce a more efficient plan. Thedefault value is on. > A correction of myself: presorted -> sorted, reordered ->sorted Thank you for your review. I think all of this make sense. Please, check the revised patch attached. ------ Regards, Alexander Korotkov Supabase
Attachment
Hi, Alexander!
On Wed, 19 Jun 2024 at 05:27, Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Tue, Jun 18, 2024 at 4:14 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
>> Controls if the query planner will produce a plan which will provide <literal>GROUP BY</literal> keys presorted in the order of keys of a child node of the plan, such as an index scan. When disabled, the query planner will produce a plan with <literal>GROUP BY</literal> keys only reordered to match
>> the <literal>ORDER BY</literal> clause, if any. When enabled, the planner will try to produce a more efficient plan. The default value is on.
> A correction of myself: presorted -> sorted, reordered ->sorted
Thank you for your review. I think all of this make sense. Please,
check the revised patch attached.
To me patch v3 looks good.
Regards,
Pavel Borisov
Supabase
On Wed, Jun 19, 2024 at 6:02 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote: > On Wed, 19 Jun 2024 at 05:27, Alexander Korotkov <aekorotkov@gmail.com> wrote: >> >> On Tue, Jun 18, 2024 at 4:14 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote: >> >> Controls if the query planner will produce a plan which will provide <literal>GROUP BY</literal> keys presorted inthe order of keys of a child node of the plan, such as an index scan. When disabled, the query planner will produce a planwith <literal>GROUP BY</literal> keys only reordered to match >> >> the <literal>ORDER BY</literal> clause, if any. When enabled, the planner will try to produce a more efficient plan.The default value is on. >> > A correction of myself: presorted -> sorted, reordered ->sorted >> >> Thank you for your review. I think all of this make sense. Please, >> check the revised patch attached. > > To me patch v3 looks good. Ok, thank you. I'm going to push this if no objections. ------ Regards, Alexander Korotkov Supabase