Re: Prepared Statement support for Parallel query

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Prepared Statement support for Parallel query
Дата
Msg-id CAA4eK1KY7JNi5h0D0UCr2YrjJrYD3Wp_Ej4aY6nS2hhzQ0xQCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Prepared Statement support for Parallel query  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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.
>

I will look into it.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Prepared Statement support for Parallel query
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Sanity checking for ./configure options?