| From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, 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-11-09 02:16:55 |
| Message-ID: | CAKU4AWpQmMdRhxwRBAL44BTzdJRi7oHj3-phinPTJS8w+qz7ig@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Unknown why people have so little interest in this, AFAICS, there are more great
usages of UniqueKey rather than the 'marking-distinct-as-noop'. The most
exciting usage for me is it is helpful for JoinRel's pathkey.
Take an example of this:
SELECT .. FROM t1 JOIN t2 ON t1.any_column = t2.uniquekey;
SELECT .. FROM t1 LEFT JOIN t2 ON t1.any_column = t2.uniquekey;
Suppose before the join, t1 has a pathkey X, t2 has PathKey y. Then
(t1.X, t2.Y) is
ordered as well for JoinRel(t1, t2). Then the pathkey of JoinRel(t1,
t2) has a lot
of usage again. Currently after the joining, only the outer join's
pathkey is maintained.
As for the extra planning cost of this, it looks like our current
infrastructure can support it
well since we know all the information when we generate the pathkey
for the Join Path.
--
Best Regards
Andy Fan (https://www.aliyun.com/)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tanghy.fnst@fujitsu.com | 2021-11-09 03:03:05 | RE: row filtering for logical replication |
| Previous Message | Michael Paquier | 2021-11-09 02:00:41 | Re: Commitfest 2021-11 Patch Triage - Part 1 |