Horton

Re: POC: GROUP BY optimization

Teodor Sigaev <teodor@sigaev.ru>

View thread
From: Teodor Sigaev <teodor@sigaev.ru>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Claudio Freire <klaussfreire@gmail.com>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2018-06-07T15:16:13Z
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

>> Again agree. If we have fixed order of columns (ORDER BY) then we should not 
>> try to reorder it. Current patch follows that if I didn't a mistake.
>>
> 
> This part seems to be more a misunderstanding between me and Claudio. I believe 
> Claudio was referring to the column order in a GROUP BY, not ORDER BY. In which 
> case we don't add any Sort, of course.
I hope so

> 
> I'm still opposed to adding arbitrary handicap to prioritize the order specified 
> by user, for the reasons I explained before. We should aim to make the 
> heuristics/costing reliable enough to make this unnecessary.
+1

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/