From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prepared Statement support for Parallel query |
Date: | 2016-02-25 07:39:25 |
Message-ID: | CA+TgmoZEm_hhxi06DuCwo1B-myjzhuuS2VmcH0xaRm-RfZBP0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 25, 2016 at 8:53 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2016-02-25 07:42:16 | Re: Identifying a message in emit_log_hook. |
Previous Message | Mithun Cy | 2016-02-25 07:27:57 | Re: POC: Cache data in GetSnapshotData() |