Horton

About 0001:,Having overviewed it, I don't see any issues (but I'm the author), except grammatical ones - but I'm not a native to judge it.,Also, the sentence 'turning GROUP BY clauses into pathkeys' is unclear to me. It may be better to write something like: 'building pathkeys by the list of grouping clauses'.,,0002:,The part under USE_ASSERT_CHECKING looks good to me. But the code in group_keys_reorder_by_pathkeys looks suspicious: of course, we do some doubtful work without any possible way to reproduce, but if we envision some duplicated elements in the group_clauses, we should avoid usage of the list_concat_unique_ptr. What's more, why do you not exit from foreach_ptr immediately after SortGroupClause has been found? I think the new_group_clauses should be consistent with the new_group_pathkeys.,,0003:,Looks good,,0004:,I was also thinking about reintroducing the preprocess_groupclause because with the re-arrangement of GROUP-BY clauses according to incoming pathkeys, it doesn't make sense to have a user-defined order—at least while cost_sort doesn't differ costs for alternative column orderings.,So, I'm okay with the code. But why don't you use the same approach with foreach_ptr as before?

Andrei Lepikhov <a.lepikhov@postgrespro.ru>

View thread
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, vignesh C <vignesh21@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Teodor Sigaev <teodor@sigaev.ru>, David Rowley <dgrowleyml@gmail.com>, "a.rybakina" <a.rybakina@postgrespro.ru>
Date: 2024-05-29T08:08:26Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Restore preprocess_groupclause()

  2. Rename PathKeyInfo to GroupByOrdering

  3. Add invariants check to get_useful_group_keys_orderings()

  4. Fix asymmetry in setting EquivalenceClass.ec_sortref

  5. Multiple revisions to the GROUP BY reordering tests

  6. Get rid of pg_class usage in SJE regression tests

  7. Rename index "abc" in aggregates.sql

  8. Explore alternative orderings of group-by pathkeys during optimization.

  9. Generalize the common code of adding sort before processing of grouping

  10. Fix out-dated comment in preprocess_groupclause()

  11. Force parallelism in partition_aggregate

  12. Optimize order of GROUP BY keys

On 5/27/24 19:41, Alexander Korotkov wrote:
> On Tue, Apr 23, 2024 at 1:19 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> While there are some particular use-cases by Jian He, I hope that
>> above could give some rationale.
> 
> I've assembled patches in this thread into one patchset.
> 0001 The patch fixing asymmetry in setting EquivalenceClass.ec_sortref
> by Andrei [1].  I've revised comments and wrote the commit message.
> 0002 The patch for handling duplicates of SortGroupClause.  I didn't
> get the sense of Andrei implementation.  It seems to care about
> duplicate pointers in group clauses list.  But the question is the
> equal SortGroupClause's comprising different pointers.  I think we
> should group duplicate SortGroupClause's together as
> preprocess_groupclause() used to do.  Reimplemented patch to do so.
> 0003 Rename PathKeyInfo to GroupByOrdering by Andres [3].  I only
> revised comments and wrote the commit message.
> 0004 Turn back preprocess_groupclause() for the reason I described upthread [4].
> 
> Any thoughts?
About 0001:
Having overviewed it, I don't see any issues (but I'm the author), 
except grammatical ones - but I'm not a native to judge it.
Also, the sentence 'turning GROUP BY clauses  into pathkeys' is unclear 
to me. It may be better to write something like:  'building pathkeys by 
the list of grouping clauses'.

0002:
The part under USE_ASSERT_CHECKING looks good to me. But the code in 
group_keys_reorder_by_pathkeys looks suspicious: of course, we do some 
doubtful work without any possible way to reproduce, but if we envision 
some duplicated elements in the group_clauses, we should avoid usage of 
the list_concat_unique_ptr. What's more, why do you not exit from 
foreach_ptr immediately after SortGroupClause has been found? I think 
the new_group_clauses should be consistent with the new_group_pathkeys.

0003:
Looks good

0004:
I was also thinking about reintroducing the preprocess_groupclause 
because with the re-arrangement of GROUP-BY clauses according to 
incoming pathkeys, it doesn't make sense to have a user-defined order—at 
least while cost_sort doesn't differ costs for alternative column orderings.
So, I'm okay with the code. But why don't you use the same approach with 
foreach_ptr as before?

-- 
regards,
Andrei Lepikhov
Postgres Professional