ORCA: limit is not pushed down to the segment if table is not analyzed

[gfphoenix78]

gpadmin=# CREATE TABLE mv_large (a int, b int, c text) USING PAX DISTRIBUTED BY (a);
INSERT INTO mv_large SELECT i, i % 1000, 'large_' || (i % 10000) FROM generate_series(1, 1000000) i;
CREATE TABLE
INSERT 0 1000000

gpadmin=# explain SELECT count(*) FROM (SELECT * FROM mv_large ORDER BY a LIMIT 100000) sub;
                                        QUERY PLAN
------------------------------------------------------------------------------------------
 Aggregate  (cost=0.00..431.00 rows=1 width=8)
   ->  Limit  (cost=0.00..431.00 rows=1 width=1)
         ->  Gather Motion 3:1  (slice1; segments: 3)  (cost=0.00..431.00 rows=1 width=4)
               Merge Key: a
               ->  Sort  (cost=0.00..431.00 rows=1 width=4)
                     Sort Key: a
                     ->  Seq Scan on mv_large  (cost=0.00..431.00 rows=1 width=4)
 Optimizer: GPORCA
(8 rows)

gpadmin=# set optimizer=off;
SET
gpadmin=# explain SELECT count(*) FROM (SELECT * FROM mv_large ORDER BY a LIMIT 100000) sub;
                                            QUERY PLAN
---------------------------------------------------------------------------------------------------
 Aggregate  (cost=2518.92..2518.93 rows=1 width=8)
   ->  Limit  (cost=1273.59..1935.17 rows=46700 width=40)
         ->  Gather Motion 3:1  (slice1; segments: 3)  (cost=1273.59..1935.17 rows=46700 width=40)
               Merge Key: mv_large.a
               ->  Limit  (cost=1273.59..1312.50 rows=15567 width=40)
                     ->  Sort  (cost=1273.59..1312.50 rows=15567 width=40)
                           Sort Key: mv_large.a
                           ->  Seq Scan on mv_large  (cost=0.00..189.67 rows=15567 width=40)
 Optimizer: Postgres query optimizer
(9 rows)

[yjhjstz]

Aggregate  (cost=0.00..437.00 rows=1 width=8)
     ->  Limit  (cost=0.00..437.00 rows=46233 width=1)            ← Global Limit only, no pushdown
           ->  Gather Motion 3:1  (rows=46233)
                 ->  Sort  (rows=15411)                             ← 15411 rows/segment
                       ->  Seq Scan on mv_large  (rows=15411)

PAX table, no ANALYZE, gp_enable_relsize_collection=on.

cdb_estimate_rel_size dispatches pg_relation_size() to QEs to get the actual PAX file size. But PAX stores data in columnar layout, not heap pages. The density formula assumes heap
layout:

density = (BLCKSZ - SizeOfPageHeaderData) / tuple_width; // ~204 tuples/page
tuples = density * curpages;

This gives 15411 rows/segment — 16x under-estimate (actual is 333333/segment).

For ORCA to push limit down, it needs per-segment rows > LIMIT/segments:

• Required: 15411 > 100000/3 = 33334
• Actual: 15411 < 33334 — not satisfied

The local limit would process 15411 rows with a cap of 33334 — it reduces nothing. The split plan adds a LocalLimit operator with cost > 0 but saves nothing on the Gather Motion.
ORCA correctly picks the cheaper non-split plan given its (wrong) estimate.

The root cause: cdb_estimate_rel_size uses a heap-specific density model that doesn't apply to PAX columnar storage. Even with real file sizes, the row estimate is fundamentally
inaccurate for non-heap table AMs.