| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel sec scan in plpgsql |
| Date: | 2016-09-22 14:02:18 |
| Message-ID: | CA+TgmobWiu2rx+u7XL+jLjv2h2iNzGMpqaFmp1VdPmi8=SUKFg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 22, 2016 at 8:36 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-09-22 14:11:20 | Re: Executor's internal ParamExecData Params versus EvalPlanQual |
| Previous Message | Robert Haas | 2016-09-22 13:55:13 | Re: Tracking wait event for latches |