Re: POC: GROUP BY optimization

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Gavin Flower <GavinFlower@archidevsys.co.nz>

Cc: pgsql-hackers@lists.postgresql.org

Date: 2018-10-02T02:16: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 →

Restore preprocess_groupclause()
- 505c008ca37c 17.0 landed
Rename PathKeyInfo to GroupByOrdering
- 0c1af2c35c7b 17.0 landed
Add invariants check to get_useful_group_keys_orderings()
- 91143c03d4ca 17.0 landed
Fix asymmetry in setting EquivalenceClass.ec_sortref
- 199012a3d844 17.0 landed
Multiple revisions to the GROUP BY reordering tests
- 874d817baa16 17.0 landed
Get rid of pg_class usage in SJE regression tests
- e1b7fde418f2 17.0 landed
Rename index "abc" in aggregates.sql
- b91f91870828 17.0 landed
Explore alternative orderings of group-by pathkeys during optimization.
- 0452b461bc40 17.0 landed
Generalize the common code of adding sort before processing of grouping
- 7ab80ac1caf9 17.0 landed
Fix out-dated comment in preprocess_groupclause()
- f6c70b81802a 15.0 landed
- 78a9af1a2764 16.0 landed
Force parallelism in partition_aggregate
- 2fe6b2a806f2 16.0 landed
- 01474f56981a 15.0 landed
Optimize order of GROUP BY keys
- db0d67db2401 15.0 landed

On Sat, Jun 30, 2018 at 09:19:13AM +1200, Gavin Flower wrote:
> Additionally put an upper limit threshold on the number of combinations to
> check, fairly large by default?
> 
> If first threshold is exceeded, could consider checking out a few more
> selected at random from paths not yet checked, to avoid any bias caused by
> stopping a systematic search.  This might prove important when N! is fairly
> large.

Please note that the latest patch available does not apply, so this has
been moved to next CF 2018-11, waiting for input from its author.
--
Michael