Обсуждение: Alternative to slow SRF in SELECT?

Поиск
Список
Период
Сортировка

Alternative to slow SRF in SELECT?

От
Markur Sens
Дата:
I have the following  case

select 
my_srf_func(otherfunc(h))
from (values (‘…’::mytype),
             ‘…’::mytype),
             (‘…’::mytype),
             ‘…’::mytype),
             (‘…’::mytype),)
         as temp(h);


I think it’s obvious what I’m trying to do.

My_srf_func is similar to unnest(array) function.

The problem now is that the result size of this could be around 400-500 elements for every function call of otherfunc(h) so when my_srf_func unnests these I should expect 2K+ items even for this simple case.

It’s also not advised to have SRFs in the SELECT of the query, becuase I do get some unexpected/unintuitive results,
but most importantly it’s way too slow.

Any alternatives on how I could rework the query or the my_srf_func to speed things up, without having too many subqueries?

I guess there should be some kind of pattern there.

If there’s any help, both my_srf_func and otherfunc are coded in PL/Python

Thanks.

Re: Alternative to slow SRF in SELECT?

От
"David G. Johnston"
Дата:
On Tue, May 17, 2022 at 7:19 AM Markur Sens <markursens@gmail.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.