Re: Optimizing nested ConvertRowtypeExpr execution

At Mon, 9 Apr 2018 16:07:33 +0530, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote in <CAFjFpRcCjqSdT70EQKUoCkfinh3VOwqZDZbg6YROzw_M0Pwd+g(at)mail(dot)gmail(dot)com>
> On Mon, Apr 9, 2018 at 3:53 PM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> > On Mon, Apr 9, 2018 at 3:49 PM, Kyotaro HORIGUCHI
> > <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >>
> >> I don't think it is not only on constatns. With the patch,
> >> non-constants are .. getting a rather strange conversion.
> >>
> >>
> >>> =# explain verbose select (a, b, c)::t1p1p1::t1p1::t1 from (select i, i * 2, i * 3 from generate_series(0, 10) i) x(a, b, c);
> >>> QUERY PLAN
> >>> -------------------------------------------------------------------------
> >> ...
> >>> Output: (ROW(i.i, (i.i * 2), (i.i * 3))::t1p1p1)::t1
> >>
> >> Conversions between scalar values cannot be assumed safely
> >> composed each other for general inputs but it is known to be safe
> >> for the ConvertRowtypeExpr case.. I think.
> >
> > I am not able to parse this statement.
> >
> > What output do you see without the patch?
> >
>
> Without the patch, I see
> explain verbose select (a, b, c)::t1p1p1::t1p1::t1 from (select i, i *
> 2, i * 3 from generate_series(0, 10) i) x(a, b, c);
> QUERY PLAN
> --------------------------------------------------------------------------------------
> Function Scan on pg_catalog.generate_series i (cost=0.00..15.00
> rows=1000 width=32)
> Output: ((ROW(i.i, (i.i * 2), (i.i * 3))::t1p1p1)::t1p1)::t1
> Function Call: generate_series(0, 10)
> (3 rows)
>
> Only difference between the two outputs is direct conversion of t1p1p1
> row into t1 row, which is what is expected with this patch. Are you
> suggesting that the optimization attempted in the patch is not safe?
> If yes, can you please explain why, and give a scenario showing its
> "un"safety?

I understood the reason for the current output. Maybe I meant the
contrary, we can remove intermediate conversions more
aggressively. I assumed that ::t1p1p1 and ::t1 yield the same
output from any input. Is it right?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center