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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Possible optimization on Function Scan
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Long options for pg_ctl waiting