| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Enabling parallelism for queries coming from SQL or other PL functions |
| Date: | 2017-03-22 23:53:19 |
| Message-ID: | CAFiTN-tE5CvZfT99YshUty_p30z=QFPOQkqeHOoWEmLcVK5O2A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 22, 2017 at 10:33 PM, Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2017-03-22 23:55:28 | Re: WIP: [[Parallel] Shared] Hash |
| Previous Message | Andres Freund | 2017-03-22 23:31:31 | Re: Logical decoding on standby |