Re: [PATCH] Keeps tracking the uniqueness with UniqueKey - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Date
Msg-id 29cca30d-6669-0f35-bae5-582e035e8b2f@iki.fi
Whole thread Raw
In response to Re: [PATCH] Keeps tracking the uniqueness with UniqueKey  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Responses RE: [PATCH] Keeps tracking the uniqueness with UniqueKey  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
Re: [PATCH] Keeps tracking the uniqueness with UniqueKey  (Andy Fan <zhihui.fan1213@gmail.com>)
List pgsql-hackers
On 30/11/2020 16:30, Jesper Pedersen wrote:
> On 11/30/20 5:04 AM, Heikki Linnakangas wrote:
>> On 26/11/2020 16:58, Andy Fan wrote:
>>> This patch has stopped moving for a while,  any suggestion about
>>> how to move on is appreciated.
>>
>> The question on whether UniqueKey.exprs should be a list of
>> EquivalenceClasses or PathKeys is unresolved. I don't have an opinion
>> on that, but I'd suggest that you pick one or the other and just go
>> with it. If it turns out to be a bad choice, then we'll change it.
> 
> In this case I think it is matter of deciding if we are going to use
> EquivalenceClasses or Exprs before going further; there has been work
> ongoing in this area for a while, so having a clear direction from a
> committer would be greatly appreciated.

Plain Exprs are not good enough, because you need to know which operator 
the expression is unique on. Usually, it's the default = operator in the 
default btree opclass for the datatype, but it could be something else, too.

There's some precedence for PathKeys, as we generate PathKeys to 
represent the DISTINCT column in PlannerInfo->distinct_pathkeys. On the 
other hand, I've always found it confusing that we use PathKeys to 
represent DISTINCT and GROUP BY, which are not actually sort orderings. 
Perhaps it would  make sense to store EquivalenceClass+opfamily in 
UniqueKey, and also replace distinct_pathkeys and group_pathkeys with 
UniqueKeys.

That's just my 2 cents though, others more familiar with this planner 
code might have other opinions...

- Heikki



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs
Next
From: Anastasia Lubennikova
Date:
Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY