Re: Optimizing nested ConvertRowtypeExpr execution

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

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Optimizing nested ConvertRowtypeExpr execution