> 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?
--
Best Regards
Andy Fan (https://www.aliyun.com/)