Re: Optimizing nested ConvertRowtypeExpr execution - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Optimizing nested ConvertRowtypeExpr execution
Date
Msg-id 20180409.194931.71492796.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Optimizing nested ConvertRowtypeExpr execution  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
At Mon, 9 Apr 2018 15:53:04 +0530, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote in
<CAFjFpReDrtM8YVmTBgHHK3p8P9wEpKPO=YurkbqukM5c1oa0cQ@mail.gmail.com>
> On Mon, Apr 9, 2018 at 3:49 PM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Optimizing nested ConvertRowtypeExpr execution
Next
From: Anthony Iliopoulos
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS