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

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

  1. Fix test case from a8ccf4e93

  2. Reordering DISTINCT keys to match input path's pathkeys