Re: Reordering DISTINCT keys to match input path's pathkeys
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
David Rowley <dgrowleyml@gmail.com>
Date: 2024-11-14T12:01:49Z
Lists: pgsql-hackers
Attachments
- minor-fix.diff (text/x-patch) patch
On 11/14/24 08:09, Richard Guo wrote: > On Wed, Nov 13, 2024 at 7:36 PM Andrei Lepikhov <lepihov@gmail.com> wrote: >> On 11/13/24 13:49, Richard Guo wrote: >> In thread [1], I try to add one more strategy that minimises the number >> of comparison operator calls. It seems that it would work the same way >> with the DISTINCT statement. Do you think it make sense in general and >> can be a possible direction of improvement for the current patch? > > I haven’t had a chance to follow that thread. From a quick look at > that patch, it seems to improve the general costing logic for sorting. > If that’s the case, I think it would be beneficial in the areas where > we use cost_sort(), including in this patch. Yes, the core of the discussion is cost calculation. It is a base for the final patch that adds a grouping strategy, according to which it may be profitable to put the column with max distinct value at the first position to make sorting less expensive. I think it makes sense to do the same in this DISTINCT feature, too (as a further improvement, of course). >> disable features during severe slowdowns or bugs. It might make sense to >> group them into a single 'Clause Reordering' parameter. > code. If these GUCs are mainly for debugging, I think it's better to > keep them separate so that we can debug each optimization individually. Ok. See minor changes I propose in the attachment. -- regards, Andrei Lepikhov
Commits
-
Fix test case from a8ccf4e93
- e15e56713702 18.0 landed
-
Reordering DISTINCT keys to match input path's pathkeys
- a8ccf4e93a7e 18.0 landed