From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, David Rowley <dgrowleyml(at)gmail(dot)com>, "a(dot)rybakina" <a(dot)rybakina(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: POC: GROUP BY optimization |
Date: | 2024-01-09 09:01:43 |
Message-ID: | add93f4d-07d8-4b95-b9be-0d84652a5943@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here is a new version of GROUP-BY optimization without sort model.
On 21/12/2023 17:53, Alexander Korotkov wrote:
> I'd like to make some notes.
>
> 1) As already mentioned, there is clearly a repetitive pattern for the
> code following after get_useful_group_keys_orderings() calls. I think
> it would be good to extract it into a separate function. Please, do
> this as a separate patch coming before the group-by patch. That would
> simplify the review.
Done. See patch 0001-*. Unfortunately, extraction of whole cycle isn't
practical, because it blows out the interface of the routine.
> 2) I wonder what planning overhead this patch could introduce? Could
> you try to measure the worst case? What if we have a table with a lot
> of indexes and a long list of group-by clauses partially patching
> every index. This should give us an understanding on whether we need
> a separate GUC to control this feature.
In current implementation I don't anticipate any significant overhead.
GUC is needed here to allow users adhere their own ordering and to
disable feature in the case of problems.
> 4) I think we can do some optimizations when enable_incremental_sort
> == off. Then in get_useful_group_keys_orderings() we should only deal
> with input_path fully matching the group-by clause, and try only full
> match of group-by output to the required order.
Hm, is it really make sense in current implementation?
--
regards,
Andrei Lepikhov
Postgres Professional
Attachment | Content-Type | Size |
---|---|---|
0001-Generalize-common-code-of-adding-sort-before-generat.patch | text/plain | 8.5 KB |
0002-Explore-alternative-orderings-of-group-by-pathkeys-d.patch | text/plain | 31.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-01-09 09:17:28 | Re: collect_corrupt_items_vacuum.patch |
Previous Message | John Naylor | 2024-01-09 09:00:45 | Re: Add BF member koel-like indentation checks to SanityCheck CI |