On Mon, Sep 19, 2016 at 11:39 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Sep 17, 2016 at 11:54 PM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
