Re: Parallel sec scan in plpgsql

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Parallel sec scan in plpgsql
Дата
Msg-id CA+TgmobWiu2rx+u7XL+jLjv2h2iNzGMpqaFmp1VdPmi8=SUKFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel sec scan in plpgsql  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Parallel sec scan in plpgsql  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Sep 22, 2016 at 8:36 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think for certain cases like into clause, the rows passed will be
> equal to actual number of rows, otherwise it will generate error.  So
> we can pass that information in executor layer.  Another kind of cases
> which are worth considering are when from plpgsql we fetch limited
> rows at-a-time, but we fetch till end like the case of
> exec_stmt_return_query().

Yes, I think that those cases can be considered.  Some careful code
inspection will be needed to make sure the cases we want to enable are
safe, and some testing will be needed to make sure they behave
properly.  But it doesn't sound like an unsolvable problem.  I hope
someone who isn't me will decide to work on it.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Tracking wait event for latches
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Executor's internal ParamExecData Params versus EvalPlanQual