Re: [BUGS] BUG #14525: select .* takes extremely long time

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [BUGS] BUG #14525: select .* takes extremely long time
Дата
Msg-id CAFj8pRAVLxT+bk8iTZN7E5yTG+3p+rVGpWBwcRwzcokTXjDc0A@mail.gmail.com
обсуждение исходный текст
Ответ на [BUGS] BUG #14525: select .* takes extremely long time  (martin.langwisch@gmx.net)
Ответы Re: [BUGS] BUG #14525: select .* takes extremely long time  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Дерево обсуждения
Hi

2017-02-02 10:05 GMT+01:00 <martin.langwisch@gmx.net>:
The following bug has been logged on the website:

Bug reference:      14525
Logged by:          Martin Langwisch
Email address:      martin.langwisch@gmx.net
PostgreSQL version: 9.6.1
Operating system:   openSUSE 11.4 (x86_64)
Description:

I have a function f that returns a composite type.
The following query:
select f().*
takes about ten times as long as either
select f()
or
select (f).* from (select f() as f) a;

It doesn't matter whether the function returns a composite type or a set of
composite type.

This behaviour strikes me as odd, to say the least and it took me quite some
time to find out why my code was so slow.

Although it looks strange - it is expected behave - and it is not a bug

XT is a composite type (a, b, c)

fx is a function with XT result.

SELECT (fx()).* is translated by parser to query SELECT fx().a, fx().b, fx().c ....

When your function fx is slow, then you cannot to use a (fx()).* pattern

Regards

Pavel

 

yours
Martin


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

Предыдущее
От: "Bogdan Bykhovets - ControlPay"
Дата:
Сообщение: [BUGS] Bug in postgres log file
Следующее
От: tiago.babo@gmail.com
Дата:
Сообщение: [BUGS] BUG #14526: no unique or exclusion constraint matching the ON CONFLICT