Re: BUG #14525: select <function>.* takes extremely long time

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: martin(dot)langwisch(at)gmx(dot)net
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14525: select <function>.* takes extremely long time
Date: 2017-02-02 12:13:10
Message-ID: CAFj8pRAVLxT+bk8iTZN7E5yTG+3p+rVGpWBwcRwzcokTXjDc0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi

2017-02-02 10:05 GMT+01:00 <martin(dot)langwisch(at)gmx(dot)net>:

> The following bug has been logged on the website:
>
> Bug reference: 14525
> Logged by: Martin Langwisch
> Email address: martin(dot)langwisch(at)gmx(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message tiago.babo 2017-02-02 14:07:01 BUG #14526: no unique or exclusion constraint matching the ON CONFLICT
Previous Message Bogdan Bykhovets - ControlPay 2017-02-02 09:14:19 Bug in postgres log file