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

From Robert Haas
Subject Re: Parallel sec scan in plpgsql
Date
Msg-id CA+TgmoY_uNECNPX1BaC-zOpFocaEoSThaeqVMmGvDV18k2j+eA@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 Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila <amit.kapila16@gmail.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parallel sec scan in plpgsql
Next
From: Robert Haas
Date:
Subject: Re: Parallel sec scan in plpgsql