| 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-20 15:01:17 |
| Message-ID: | CA+TgmoY_uNECNPX1BaC-zOpFocaEoSThaeqVMmGvDV18k2j+eA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> I think here point is that for any case where there is count of rows
> to be selected, we disable parallelism. There are many genuine cases
> like select count(*) into cnt ... which will run to completion, but as
> plpgsql passes row count to be 1 or 2, it doesn't enter parallel mode.
> There are couple other cases like that. Do you see a reason for not
> enabling parallelism for such cases?
If we can somehow know that the rowcount which is passed is greater
than or equal to the actual number of rows which will be generated,
then it's fine to enable parallelism.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-09-20 15:02:53 | Re: Parallel sec scan in plpgsql |
| Previous Message | Tom Lane | 2016-09-20 14:58:17 | Re: Parallel sec scan in plpgsql |