Horton

Re: POC: GROUP BY optimization

Ibrar Ahmed <ibrar.ahmad@gmail.com>

View thread
From: Ibrar Ahmed <ibrar.ahmad@gmail.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Teodor Sigaev <teodor@sigaev.ru>, Gavin Flower <GavinFlower@archidevsys.co.nz>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-05T11:37:30Z
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

Attachments

On Thu, Oct 29, 2020 at 8:15 PM Pavel Borisov <pashkin.elfe@gmail.com>
wrote:

> In case if I'm missing something and Pavel's proposal is significantly
>> different from the original patch (if I understand correctly, at the
>> moment the latest patch posted here is a rebase and adjusting the old
>> patch to work with the latest changes in master, right?), then indeed
>> they could be merged, but please in the newer thread [1].
>>
>
> Sure, my patch has the only difference from the previous Theodor's code
> for compatibility with v.13, though it is not small, and I appreciate the
> changes in paths processing. The only thing that caused my notice, is that
> some useful changes which I've mentioned before, are discarded now. But as
> long as they are planned to be put in later it is completely fine. I agree
> to discuss the thing in any thread, though I don't quite understand the
> reason for a switch.
>
> Still I don't see a problem.
>
> --
> Best regards,
> Pavel Borisov
>
> Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
>

Regression (stats_ext)  is failing because you forgot to drop the table
created in a test
case (aggregates),  It's a bit minor change so the attached patch fixes
that issue.

https://cirrus-ci.com/task/6704792446697472


-- 
Ibrar Ahmed