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+TgmoZEm_hhxi06DuCwo1B-myjzhuuS2VmcH0xaRm-RfZBP0w@mail.gmail.com
Whole thread Raw
In response to Re: Prepared Statement support for Parallel query  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Prepared Statement support for Parallel query
List pgsql-hackers
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.

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



pgsql-hackers by date:

Previous
From: Mithun Cy
Date:
Subject: Re: POC: Cache data in GetSnapshotData()
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Identifying a message in emit_log_hook.