Re: The flinfo->fn_extra question, from me this time.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: The flinfo->fn_extra question, from me this time.
Дата
Msg-id 12389.1563746057@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: The flinfo->fn_extra question, from me this time.  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: The flinfo->fn_extra question, from me this time.  (Dent John <denty@QQdd.eu>)
Re: The flinfo->fn_extra question, from me this time.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> Until now, I had assumed that SFRM_ValuePerCall mode might offer some
> benefits, such as the possibility of pipelining certain queries and not
> building up a whole tuplestore in advance.

> But looking in the code, I'm getting the impression that those
> benefits are only theoretical future ones, as ExecMakeTableFunctionResult
> implements SFRM_ValuePerCall mode by ... repeatedly calling the function
> to build up a whole tuplestore in advance.

Yes, that's the case for a SRF in FROM.  A SRF in the targetlist
actually does get the chance to pipeline, if it implements ValuePerCall.

The FROM case could be improved perhaps, if somebody wanted to put
time into it.  You'd still need to be prepared to build a tuplestore,
in case of rescan or backwards fetch; but in principle you could return
rows immediately while stashing them aside in a tuplestore.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: The flinfo->fn_extra question, from me this time.
Следующее
От: David Rowley
Дата:
Сообщение: Re: Performance issue in foreign-key-aware join estimation