Re: Optimizing nested ConvertRowtypeExpr execution

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Optimizing nested ConvertRowtypeExpr execution
Дата
Msg-id 20180409.195901.222521039.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Optimizing nested ConvertRowtypeExpr execution  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: Optimizing nested ConvertRowtypeExpr execution  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
At Mon, 9 Apr 2018 16:07:33 +0530, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote in
<CAFjFpRcCjqSdT70EQKUoCkfinh3VOwqZDZbg6YROzw_M0Pwd+g@mail.gmail.com>
> On Mon, Apr 9, 2018 at 3:53 PM, Ashutosh Bapat
> <ashutosh.bapat@enterprisedb.com> wrote:
> > 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.
> >
> > 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



В списке pgsql-hackers по дате отправления:

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