On Tue, Jul 13, 2021 at 5:55 PM Andy Fan <zhihui.fan1213@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/)
