Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series) - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Date
Msg-id CAKU4AWog2R9BqOYxfJ3+Ld48YaSTnF0uvbgZ=oUB9ZwGg51erg@mail.gmail.com
Whole thread Raw
In response to Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)  (Andy Fan <zhihui.fan1213@gmail.com>)
Responses Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
List pgsql-hackers
> 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/)



pgsql-hackers by date:

Previous
From: "Mikhail Kulagin"
Date:
Subject: RE: [PATCH] Pull general SASL framework out of SCRAM
Next
From: Masahiro Ikeda
Date:
Subject: Re: Fix comments of heap_prune_chain()