On Thu, Aug 3, 2023 at 12:38 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote:
> On Tue, Aug 1, 2023 at 6:50 PM Tom Lane <t...@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. Thanks Richard