Re: Optimizing nested ConvertRowtypeExpr execution

At Mon, 9 Apr 2018 15:53:04 +0530, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote in <CAFjFpReDrtM8YVmTBgHHK3p8P9wEpKPO=YurkbqukM5c1oa0cQ(at)mail(dot)gmail(dot)com>
> 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.

I apologize for the unreadable statement..

> What output do you see without the patch?

I got the following on the master.

> Output: ((ROW(i.i, (i.i * 2), (i.i * 3))::t1p1p1)::t1p1)::t1

And I expect the following with this patch.

> Output: ROW(i.i, (i.i * 2), (i.i * 3))::t1

And what the current patch generates looks imcomplete to me.

> >> Output: (ROW(i.i, (i.i * 2), (i.i * 3))::t1p1p1)::t1

I try to reword the unreadable thing..

We get the similar composition of casts on scalar values.

> =# explain verbose select 1::text::int::float;
..
> Output: '1'::double precision

But we don't get the same on non-constant.

> =# explain verbose select x::text::int::float from generate_series(0, 10) x;
...
> Output: (((x)::text)::integer)::double precision

This seems reasonable since we cannot assume that "::double
precision" and "::text::integer::double precision" are equivelant
on arbitrary (or undecided, anyway I'm not sure it is true)
input. But ConvertRowtypeExpr seems to be composable (or
mergeable) for arbitrary input. Otherwise composition (or
merging) of ConvertRowtypeExpr should not be performed at all.

# I wish this makes sense..

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center