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
