Re: Oversight in reparameterize_path_by_child leading to executor crash

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

> 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.

Thanks
Richard