Hi, Andrei! Thank you for your feedback.
On Wed, May 29, 2024 at 11:08 AM Andrei Lepikhov <a.lepik...@postgrespro.ru> wrote: > On 5/27/24 19:41, Alexander Korotkov wrote: > > On Tue, Apr 23, 2024 at 1:19 AM Alexander Korotkov <aekorot...@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'. OK, thank you. I'll run once again for the grammar issues. > 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. As I understand Tom, there is a risk that clauses list may contain multiple instances of equivalent SortGroupClause, not duplicate pointers. > 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. I wanted this to be consistent with preprocess_groupclause(), where duplicate SortGroupClause'es are grouped together. Otherwise, we could just delete redundant SortGroupClause'es. > 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? I restored the function as it was before 0452b461bc with minimal edits to support the incremental sort. I think it would be more valuable to keep the difference with pg16 code small rather than refactor to simplify existing code. ------ Regards, Alexander Korotkov
