Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
| От | Rafia Sabih |
|---|---|
| Тема | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions |
| Дата | |
| Msg-id | CAOGQiiMU9UNA9C3Bsawv0ButL=VttWpJe=RZC96jWFXeNj8omQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
|
| Список | pgsql-hackers |
On Wed, Mar 8, 2017 at 1:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
Here's a draft patch showing the sort of thing I have in mind. I
think it needs more work, but it gives you the idea, I hope. This is
loosely based on your pl_parallel_exec_support_v1.patch, but what I've
done here is added some flags that carry the information about whether
there will be only one or maybe more than one call to ExecutorRun to a
bunch of relevant places.
I think this might have the effect of disabling parallel query in some
cases where PL/pgsql currently allows it, and I think that may be
necessary. (We may need to back-patch a different fix into 9.6.)
I wanted to clarify a few things here, I noticed that call of ExecutorRun in postquel_getnext() uses !es->lazyEval as execute_once, this is confusing, as it is true even in cases when a simple query like "select count(*) from t" is used in a sql function. Hence, restricting parallelism for cases when it shouldn't. It seems to me that es->lazyEval is not set properly or it should not be true for simple select statements. I found that in the definition of execution_state
bool lazyEval; /* true if should fetch one row at a time */
and in init_execution_state, there is a comment saying,
* Mark the last canSetTag query as delivering the function result; then,
* if it is a plain SELECT, mark it for lazy evaluation. If it's not a
* SELECT we must always run it to completion.
I find these two things contradictory to each other. So, is this point missed or is there some deep reasoning behind that?
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: