On Tue, Apr 6, 2021 at 6:55 PM David Rowley <dgrowle...@gmail.com> wrote:
>
> On Tue, 6 Apr 2021 at 22:31, Andy Fan <zhihui.fan1...@gmail.com> wrote:
> > On Wed, Mar 31, 2021 at 9:12 PM Ashutosh Bapat
> > <ashutosh.bapat....@gmail.com> wrote:
> >> I think the reason we add ECs for sort expressions is to use
> >> transitive relationship. The EC may start with a single member but
> >> later in the planning that member might find partners which are all
> >> equivalent. Result ordered by one is also ordered by the other. The
> >> same logic applies to UniqueKey as well, isn't it. In a result if a
> >> set of columns makes a row unique, the set of columns represented by
> >> the other EC member should be unique. Though a key will start as a
> >> singleton it might EC partners later and thus thus unique key will
> >> transition to all the members. With that logic UniqueKey should use
> >> just ECs instead of bare expressions.
> >
> >
> > TBH, I haven't thought about this too hard, but I think when we build the
> > UniqueKey, all the ECs have been built already. So can you think out an
> > case we start with an EC with a single member at the beginning and
> > have more members later for UniqueKey cases?
>
> I don't really know if it matters which order things happen. We still
> end up with a single EC containing {a,b} whether we process ORDER BY b
> or WHERE a=b first.
>
I think it is time to talk about this again. Take the below query as example:
SELECT * FROM t1, t2 WHERE t1.pk = t2.pk;
Then when I populate_baserel_uniquekeys for t1, we already have
EC{Members={t1.pk, t2.pk}} in root->eq_classes already. Then I use
this EC directly for t1's UniqueKey. The result is:
T1's UniqueKey : [ EC{Members={t1.pk, t2.pk}} ].
*Would this be OK since at the baserel level, the "t1.pk = t2.pk" is not
executed yet?*
I tried the below example to test how PathKey is maintained.
CREATE TABLE t1 (a INT, b INT);
CREATE TABLE t2 (a INT, b INT);
CREATE INDEX ON t1(b);
SELECT * FROM t1, t2 WHERE t1.b = t2.b and t1.b > 3;
then we can get t1's Path:
Index Scan on (b), PathKey.pk_class include 2 members (t1.b, t2.b}
even before the Join.
So looks the answer for my question should be "yes"? Hope I have
made myself clear.
--
Best Regards
Andy Fan (https://www.aliyun.com/)
