UniqueKey is a set of exprs on RelOptInfo, the result is unique for sure 
by definition.  Some simple examples on baserel would be:

CREATE TABLE t(a int primary key, b int not null, c int, d int);
CREATE UNIQUE INDEX on t(b);
CREATE UNIQUE INDEX on t(c);

SELECT a FROM t; -- A is UniqueKey since it is primary key.
SELECT b FROM t; -- B is UniqueKey since it is not null unique index.
SELECT c FROM t WHERE c > 0;  -- The output c (after c > 0 is evaluated is
unique key.
SELECT d FROM t WHERE a = d;  -- the output d is unique is unique since d = a
and a is unique.
SELECT d FROM t WHERE a = 1;  -- the output d is unique since only 1 value is
returned.


What's the values of UniqueKey:

After 2+ years experience on this topic, I found more and more user cases. Here
are some highlight interesting use case for now, even only mark the DISTINCT as
no-op is my first motivation.

1. Remove duplicated DISTINCT clause automatically. Users are so likely to add
   a DISTINCT to grantee the result is unique, but in fact, it is unique for
   sure, we can remove this expensive node totally.

2. Improve the PathKey of JoinRel, then PathKey would has lots of user case,
   The new finding would be helpful both planning time and better final plan.

   SELECT .. FROM t1 JOIN t2 ON t1.any_column = t2.uniquekey;

   Suppose t1 has a pathkey X, t2 has PathKey y. Then (t1.X,t2.Y) is ordered as
   well for JoinRel(t1, t2).  At current master branch, only the outer join's
   pathkey is maintained after join.

3. Improve PathKey because of single row case, then planning time can be reduced
   a lot as well.

   SELECT * FROM d WHERE pk = 1;

   Then the each output columns t is ordered as well.  In some dimension table,
   which would be joined with lots of table, like

   SELECT * FROM d JOIN f1 ON d.pk = 1 AND f1.fk = d.pk JOIN f2 ON f2.fk = d.pk;

   Usually dimension table are pretty small. So the cheapest path probably be
   SeqScan so the output column is no ordered.  Index Scan on d is ordered but
   not the cheapest path so both paths are kept. This may make the later join
   has more paths to compare.  Ideally with the UniqueKey infrastructure, we can
   detect if the output is single row, if so, we can say the output column is
   ordered even it is SeqScan, then only 1 paths are kept, so planning time can
   be saved a lot.

4. Current planner have lots of user case of uniqueness, the fully supported
   UniqueKey may help on these user case as well.