| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Zhihong Yu <zyu(at)yugabyte(dot)com>, "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: POC: GROUP BY optimization |
| Date: | 2022-07-13 03:37:19 |
| Message-ID: | CAApHDvq65=9Ro+hLX1i9ugWEiNDvHrBibAO7ARcTnf38_JE+UQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 31 Mar 2022 at 12:19, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> Pushed, after going through the patch once more, running check-world
> under valgrind, and updating the commit message.
I'm just in this general area of the code again today and wondered
about the header comment for the preprocess_groupclause() function.
It says:
* In principle it might be interesting to consider other orderings of the
* GROUP BY elements, which could match the sort ordering of other
* possible plans (eg an indexscan) and thereby reduce cost. We don't
* bother with that, though. Hashed grouping will frequently win anyway.
I'd say this commit makes that paragraph mostly obsolete. It's only
true now in the sense that we don't try orders that suit some index
that would provide pre-sorted results for a GroupAggregate path. The
comment leads me to believe that we don't do anything at all to find a
better order, and that's not true now.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joseph D Wagner | 2022-07-13 03:49:10 | Re: proposal: Allocate work_mem From Pool |
| Previous Message | Sandeep Thakkar | 2022-07-13 03:30:10 | Re: "ERROR: latch already owned" on gharial |