On Tue, Aug 1, 2023 at 6:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alternatively, could we postpone the reparameterization until > createplan.c? Having to build reparameterized expressions we might > not use seems expensive, and it would also contribute to the memory > bloat being complained of in nearby threads.
As long as the translation happens only once, it should be fine. It's the repeated translations which should be avoided.
Sometimes it would help to avoid the translation at all if we postpone the reparameterization until createplan.c, such as in the case that a non-parameterized path wins at last. For instance, for the query below
regression=# explain (costs off) select * from prt1 t1 join prt1 t2 on t1.a = t2.a; QUERY PLAN -------------------------------------------- Append -> Hash Join Hash Cond: (t1_1.a = t2_1.a) -> Seq Scan on prt1_p1 t1_1 -> Hash -> Seq Scan on prt1_p1 t2_1 -> Hash Join Hash Cond: (t1_2.a = t2_2.a) -> Seq Scan on prt1_p2 t1_2 -> Hash -> Seq Scan on prt1_p2 t2_2 -> Hash Join Hash Cond: (t1_3.a = t2_3.a) -> Seq Scan on prt1_p3 t1_3 -> Hash -> Seq Scan on prt1_p3 t2_3 (16 rows)
Our current code would reparameterize each inner paths although at last we choose the non-parameterized paths. If we do the reparameterization in createplan.c, we would be able to avoid all the translations.