On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Sep 17, 2016 at 11:54 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> In general, I think we should support the cases as required (or
>> written) by you from plpgsql or sql functions. We need more work to
>> support such cases. There are probably two ways of supporting such
>> cases, we can build some intelligence in plpgsql execution such that
>> it can recognise such queries and allow to use parallelism or we need
>> to think of enabling parallelism for cases where we don't run the plan
>> to completion. Most of the use cases from plpgsql or sql function
>> fall into later category as they don't generally run the plan to
>> completion.
>
> I think there's certainly more work that could be done to teach
> PL/pgsql about cases where the query will run to completion. I didn't
> work very hard to make sure we covered all of those; there are
> probably several different cases where parallelism could be safely
> enabled but currently isn't. Also, I didn't do anything at all to
> update the other PLs, and that would be good, too.
>
> However, I think the chances of supporting parallel query for queries
> not executed to completion any time in the near future are very poor.
>
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?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com