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.
I agree. The costs do not change because of reparameterization. The process of creating paths is to estimate costs of different plans. So I think it makes sense to delay anything which doesn't contribute to costing till the final plan is decided.
However, if reparameterization can *not* happen at the planning time, we have chosen a plan which can not be realised meeting a dead end. So as long as we can ensure that the reparameterization is possible we can delay actual translations. I think it should be possible to decide whether reparameterization is possible based on the type of path alone. So seems doable.