Re: Enabling parallelism for queries coming from SQL or other PL functions

From: Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(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-23 04:41:02
Message-ID: CAOGQiiOt+JvnB5EfBsk-=fk2RikjEGEXdiS7gdrtAv4sfSGT3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 23, 2017 at 5:23 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> 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.
>
Agree, done.

--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/

Attachment Content-Type Size
execute-once-v3.patch application/octet-stream 16.6 KB
pl_parallel_opt_support_v3.patch application/octet-stream 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-03-23 04:41:26 Re: Logical decoding on standby
Previous Message Ashutosh Sharma 2017-03-23 04:32:14 Re: pageinspect and hash indexes