Re: Oversight in reparameterize_path_by_child leading to executor crash

On Thu, Aug 3, 2023 at 4:14 PM Richard Guo <guofenglinux@gmail.com> wrote:

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