Re: POC: GROUP BY optimization - Mailing list pgsql-hackers

From Richard Guo
Subject Re: POC: GROUP BY optimization
Date
Msg-id CAMbWs48MSejYST6pX8q-rEJMmRwo+fycDpc5vkkDusc=KF5y7Q@mail.gmail.com
Whole thread Raw
In response to Re: POC: GROUP BY optimization  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: POC: GROUP BY optimization
List pgsql-hackers

On Wed, Feb 21, 2024 at 6:20 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
Hi, Richard!

> What do you think about the revisions for the test cases?

I've rebased your patch upthread.  Did some minor beautifications.

> * The table 'btg' is inserted with 10000 tuples, which seems a bit
> expensive for a test.  I don't think we need such a big table to test
> what we want.

Your patch reduces the number of rows to 1000 tuples.  I found it
possible to further reduce it to 100 tuples.  That also allowed me to
save the plan in the test case introduced by e1b7fde418.

Please check if you're OK with the patch attached.

I looked through the v2 patch and have two comments.

* The test case under "Check we don't pick aggregate path key instead of
grouping path key" does not have EXPLAIN to show the plan.  So how can
we ensure we do not mistakenly select the aggregate pathkeys instead of
the grouping pathkeys?

* I don't think the test case introduced by e1b7fde418 is still needed,
because we already have one under "Utilize the ordering of merge join to
avoid a full Sort operation".  This kind of test case is just to ensure
that we are able to utilize the ordering of the subplans underneath.  So
it should be parallel to the test cases for utilize the ordering of
index scan and subquery scan.

See the attached v3 patch.  I also made cosmetic tweaks to the comments,
and simplified a test case query.

Thanks
Richard
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Speeding up COPY TO for uuids and arrays
Next
From: Melanie Plageman
Date:
Subject: Re: Add LSN <-> time conversion functionality