Underestimated number of output rows with an aggregate function

Hi all,

Working on the emaj extension (for the curious ones, 
https://emaj.readthedocs.io/en/latest/ and 
https://github.com/dalibo/emaj), I recently faced a performance problem 
when querying and aggregating data changes. A query with 3 CTE has a O^2 
behavior (https://explain.dalibo.com/plan/1ded242d4ebf3gch#plan). I have 
found a workaround by setting enable_nestloop to FALSE. But this has 
drawbacks. So I want to better understand the issue.

During my analysis, I realized that the output rows estimate of the 
second CTE is really bad, leading to a bad plan for the next CTE.

I reproduced the issue in a very small test case with a simplified 
query. Attached is a shell script and its output.

A simple table is created, filled and analyzed.

The simplified statement is:
  WITH keys AS (
    SELECT c1, min(seq) AS seq FROM perf GROUP BY c1
    )
  SELECT tbl.*
    FROM perf tbl JOIN keys ON (keys.c1 = tbl.c1 AND keys.seq = tbl.seq);

Its plan is:
  Hash Join (cost=958.00..1569.00 rows=1 width=262) (actual 
time=18.516..30.702 rows=10000 loops=1)
    Output: tbl.c1, tbl.seq, tbl.c2
    Inner Unique: true
    Hash Cond: ((tbl.c1 = perf.c1) AND (tbl.seq = (min(perf.seq))))
    Buffers: shared hit=856
    ->  Seq Scan on public.perf tbl  (cost=0.00..548.00 rows=12000 
width=262) (actual time=0.007..2.323 rows=12000 loops=1)
          Output: tbl.c1, tbl.seq, tbl.c2
          Buffers: shared hit=428
    ->  Hash  (cost=808.00..808.00 rows=10000 width=8) (actual 
time=18.480..18.484 rows=10000 loops=1)
          Output: perf.c1, (min(perf.seq))
          Buckets: 16384  Batches: 1  Memory Usage: 519kB
          Buffers: shared hit=428
          ->  HashAggregate  (cost=608.00..708.00 rows=10000 width=8) 
(actual time=10.688..14.321 rows=10000 loops=1)
                Output: perf.c1, min(perf.seq)
                Group Key: perf.c1
                Batches: 1  Memory Usage: 1425kB
                Buffers: shared hit=428
                ->  Seq Scan on public.perf (cost=0.00..548.00 
rows=12000 width=8) (actual time=0.002..2.330 rows=12000 loops=1)
                      Output: perf.c1, perf.seq, perf.c2
                      Buffers: shared hit=428

It globally looks good to me, with 2 sequential scans and a hash join.
But the number of returned rows estimate is always 1, while it actually 
depends on the data content (here 10000).

For the hash join node, the plan shows a "Inner Unique: true" property. 
I wonder if this is normal. It look likes the optimizer doesn't take 
into account the presence of the GROUP BY clause in its estimate.

I reproduce the case with all supported postgres versions.

Thanks by advance for any explanation.
Philippe.