Re: [BUGS] BUG #14525: select .* takes extremely long time - Mailing list pgsql-bugs

From Pavel Stehule
Subject Re: [BUGS] BUG #14525: select .* takes extremely long time
Date
Msg-id CAFj8pRAVLxT+bk8iTZN7E5yTG+3p+rVGpWBwcRwzcokTXjDc0A@mail.gmail.com
Whole thread Raw
In response to [BUGS] BUG #14525: select .* takes extremely long time  (martin.langwisch@gmx.net)
Responses Re: [BUGS] BUG #14525: select .* takes extremely long time  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Bogdan Bykhovets - ControlPay"
Date:
Subject: [BUGS] Bug in postgres log file
Next
From: tiago.babo@gmail.com
Date:
Subject: [BUGS] BUG #14526: no unique or exclusion constraint matching the ON CONFLICT