Re: Parallel sec scan in plpgsql - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel sec scan in plpgsql
Date
Msg-id CA+TgmobWiu2rx+u7XL+jLjv2h2iNzGMpqaFmp1VdPmi8=SUKFg@mail.gmail.com
Whole thread Raw
In response to Re: Parallel sec scan in plpgsql  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel sec scan in plpgsql  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Tracking wait event for latches
Next
From: Tom Lane
Date:
Subject: Re: Executor's internal ParamExecData Params versus EvalPlanQual