On Thu, Aug 3, 2023 at 4:14 PM Richard Guo <guofengli...@gmail.com> wrote:
> > On Thu, Aug 3, 2023 at 12:38 PM Ashutosh Bapat < > ashutosh.bapat....@gmail.com> wrote: > > 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. -- Best Wishes, Ashutosh Bapat
