Re: Optimizing nested ConvertRowtypeExpr execution

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Optimizing nested ConvertRowtypeExpr execution
Дата
Msg-id 20180409.194931.71492796.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Optimizing nested ConvertRowtypeExpr execution  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Optimizing nested ConvertRowtypeExpr execution
Следующее
От: Anthony Iliopoulos
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS