Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, Floris Van Nee <florisvannee(at)optiver(dot)com>
Subject: Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Date: 2021-07-15 09:33:53
Message-ID: CAKU4AWqYSzwU+oQwZnEi5MfVec83gGPYCyiGUXNJig9r=g0CMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2021-07-15 09:35:33 Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails
Previous Message r.takahashi_2@fujitsu.com 2021-07-15 09:25:16 RE: Transactions involving multiple postgres foreign servers, take 2