On Tue, Jul 13, 2021 at 5:55 PM Andy Fan <zhihui.fan1...@gmail.com> wrote: > > > 4. Cut the useless UniqueKey totally on the baserel stage based on > > root->distinct_pathkey. If we want to use it anywhere else, I think this > > design is OK as well. for example: group by UniqueKey. > > > > The intention of this is I want to cut off the useless UniqueKey ASAP. In the > previous patch, I say "if the unique_exprs not exists in root->distinct_paths, > then it is useless". However This looks only works for single rel. As for the > joinrel, we have to maintain the UniqueKey on mergeable join clause for the > case > like below. > > SELECT DISTINCT t1.pk FROM t1, t2 WHERE t1.a = t2.pk; > or > SELECT DISTINCT t1.pk FROM t1 left join t2 on t1.a = t2.pk; > > In this case, t2.pk isn't shown in distinct_pathkey, but it is still useful at > the join stage and not useful after joining. > > So how can we maintain the UniqueKey like t2.pk? > 1). If t2.pk exists in root->eq_classes, keep it. > 2). If t2.pk doesn't exist in RelOptInfo->reltarget after joining, discard it. > > Step 1 is not so bad since we have RelOptInfo.eclass_indexes. However step 2 > looks pretty boring since we have to check on every RelOptInfo and we may have > lots of RelOptInfo. > > Any suggestions on this? >
Just a function like truncate_useless_pathkey would be OK. For that we need to handle uniquekey_useful_for_merging and uniquekey_useful_for_distinct. -- Best Regards Andy Fan (https://www.aliyun.com/)