Re: Prepared Statement support for Parallel query - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Prepared Statement support for Parallel query
Date
Msg-id CA+TgmoaxyXVr6WPDvPQduQpFhD9VRWExXU7axhDpJ7jZBvqxfQ@mail.gmail.com
Whole thread Raw
In response to Re: Prepared Statement support for Parallel query  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Prepared Statement support for Parallel query
Re: Prepared Statement support for Parallel query
List pgsql-hackers
On Thu, Feb 25, 2016 at 1:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Feb 25, 2016 at 8:53 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>>   But if the user says
>>> they want to PREPARE the query, they are probably not going to fetch
>>> all rows.
>>
>> After PREPARE, user will execute the statement using EXECUTE and
>> I don't see how user can decide number of rows to fetch which can
>> influence the execution.  Can you please elaborate your point more
>> and what is your expectation for the same?
>
> Argh.  I'm getting confused between prepared statements and cursors.
> So if the user does PREPARE followed by EXECUTE, then that is OK.  The
> problem is only if they use DECLARE .. CURSOR FOR, which your patch
> doesn't affect.
>
> So, committed.

And, I'm going to revert this part.  If you'd run the regression tests
under force_parallel_mode=regress, max_parallel_degree>0, you would
have noticed that this part breaks it, because of CREATE TABLE ... AS
EXECUTE.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: get current log file
Next
From: Amit Kapila
Date:
Subject: Re: Prepared Statement support for Parallel query