Re: Oversight in reparameterize_path_by_child leading to executor crash

On Thu, Aug 3, 2023 at 4:14 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:

>
> On Thu, Aug 3, 2023 at 12:38 PM Ashutosh Bapat <
> ashutosh(dot)bapat(dot)oss(at)gmail(dot)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