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.
Once the query is suspended, the user can do anything they like,
including stuff that's parallel-unsafe, and then we have no choice but
to error out, and that's not what we want to happen. If we had
absolutely no parallel-unsafe operations - which would be quite a feat
- then we might be able to get there. But even then you have the
problem that while the query is suspended, you are still nailing down
workers that are sitting around idle, waiting for the leader to resume
the query, and that's not very good either.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company