Re: Optimizing nested ConvertRowtypeExpr execution

At Fri, 6 Apr 2018 08:37:57 +0200, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote in <CAFj8pRAR9dL6Hw8EMb=QLHn-_WvafZNV9R40A4fZHr+qd7KXPg(at)mail(dot)gmail(dot)com>
> 2018-04-06 8:21 GMT+02:00 Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>:
>
> > On Tue, Apr 3, 2018 at 10:48 AM, Ashutosh Bapat
> > <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> > >>
> > >> Why is this done appropriately at ExecInitExpr() time, rather than at
> > >> plan time? Seems like eval_const_expressions() would be a bit more
> > >> appropriate (being badly named aside...)?
> > >
> > > That seems to be a better idea. Here's patch.
> > >
> >
> > Previous patch didn't try to fold the ConvertRowtypeExpr::arg into a Const.
> >
> > postgres=# create table t1 (a int, b int, c int) partition by range(a);
> > postgres=# create table t1p1 partition of t1 for values from (0) to
> > (100) partition by range(b);
> > postgres=# create table t1p1p1 partition of t1p1 for values from (0) to
> > (50);
> > postgres=# explain verbose select (1, 2, 3)::t1p1p1::t1p1::t1; --
> > notice Rowexpression here.
> > QUERY PLAN
> > -------------------------------------------
> > Result (cost=0.00..0.01 rows=1 width=32)
> > Output: (ROW(1, 2, 3)::t1p1p1)::t1
> > (2 rows)
> >
> > Here's patch fixing that. With this patch
> > postgres=# explain verbose select (1, 2, 3)::t1p1p1::t1p1::t1;
> > QUERY PLAN
> > -------------------------------------------
> > Result (cost=0.00..0.01 rows=1 width=32)
> > Output: '(1,2,3)'::t1
> > (2 rows)
> >
> >
> +1

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.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center