From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Markur Sens <markursens(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Alternative to slow SRF in SELECT? |
Date: | 2022-05-17 14:33:14 |
Message-ID: | CAKFQuwY=jQLdnv4LtAm8hDdJTnQPjT55iWNcjUmrNu1pEY_ZHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, May 17, 2022 at 7:19 AM Markur Sens <markursens(at)gmail(dot)com> wrote:
> I have the following case
>
>
> select
> my_srf_func(otherfunc(h))
> from (values (‘…’::mytype),
>
> as temp(h);
>
>
>
> Any alternatives on how I could rework the query or the my_srf_func to speed things up, without having too many subqueries?
>
>
Placing the SRF function in the target list is now largely deprecated.
Table producing functions belong in the FROM clause. The introduction of
LATERAL joins made this possible. My preference is to retain the JOIN
syntax.
SELECT *
FROM (...) AS temp (h)
JOIN my_srf_func(h) ON true
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-05-17 14:53:01 | Re: Restricting user to see schema structure |
Previous Message | Markur Sens | 2022-05-17 14:19:51 | Alternative to slow SRF in SELECT? |