Re: Possible optimization on Function Scan
От | Andres Freund |
---|---|
Тема | Re: Possible optimization on Function Scan |
Дата | |
Msg-id | 20160907203153.xkphqeb7rfaixwjs@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Possible optimization on Function Scan (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | pgsql-hackers |
Hi, On 2016-09-07 15:29:08 -0500, Jim Nasby wrote: > I was a bit surprised to discover the difference below in calling an SRF as > part of a target list vs part of the from clause. The from clause generates > a Function Scan, which (apparently blindly) builds a tuplestore. Is there a > relatively easy way to either transform this type of query so the SRF is > back in a target list, or teach Function Scan that it doesn't always need to > create a tuplestore? It would be nice if we could just not use a tuplestore > at all (depending on the planner to add a Materialize node if necessary), > but AIUI functions can directly return a tuplestore, so I guess that's not > an option... I've recently implemented ValuePerCall support for SRF in FROM http://archives.postgresql.org/message-id/20160827214829.zo2dfb5jaikii5nw%40alap3.anarazel.de One mail up in https://www.postgresql.org/message-id/20160822214023.aaxz5l4igypowyri%40alap3.anarazel.de there's before/after performance numbers showing that removing the materialization fixes the issue. Andres
В списке pgsql-hackers по дате отправления: