Re: Oversight in reparameterize_path_by_child leading to executor crash

On Thu, Aug 3, 2023 at 12:38 PM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> On Tue, Aug 1, 2023 at 6:50 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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