Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions
| От | Dilip Kumar | 
|---|---|
| Тема | Re: [HACKERS] Enabling parallelism for queries coming from SQL orother PL functions | 
| Дата | |
| Msg-id | CAFiTN-tE5CvZfT99YshUty_p30z=QFPOQkqeHOoWEmLcVK5O2A@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 22, 2017 at 10:33 PM, Robert Haas <robertmhaas@gmail.com> wrote: > So couldn't we actually make this test !fcache->returnsSet || !es->lazyEval? > That would let us allow parallel execution for all non-set-returning > functions, and also for set-returning functions that end up with > es->lazyEval set to false. Yes, this is the right thing to do although we may not enable parallelism for any more queries by adding "|| !es->lazyEval". Because SELECT are always marked as es->lazyEval=true(And so far we have parallelism only for select). But here we calling the parameter to ExecutorRun as execute_once so !fcache->returnsSet || !es->lazyEval is the correct one and future proof. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: