Re: Parallel execution and prepared statements
От | Robert Haas |
---|---|
Тема | Re: Parallel execution and prepared statements |
Дата | |
Msg-id | CA+TgmobA5yNxfL6Rp-JDgF=OjGvEmdyDDkv2fKLJvCY2Q=xMTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Parallel execution and prepared statements (Albe Laurenz <laurenz.albe@wien.gv.at>) |
Ответы |
Re: Parallel execution and prepared statements
|
Список | pgsql-hackers |
On Tue, Nov 15, 2016 at 10:41 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: > Tobias Bussmann has discovered an oddity with prepared statements. > > Parallel scan is used with prepared statements, but only if they have > been created with protocol V3 "Parse". > If a prepared statement has been prepared with the SQL statement PREPARE, > it will never use a parallel scan. > > I guess that is an oversight in commit 57a6a72b, right? > PrepareQuery in commands/prepare.c should call CompleteCachedPlan > with cursor options CURSOR_OPT_PARALLEL_OK, just like > exec_prepare_message in tcop/postgres.c does. > > The attached patch fixes the problem for me. Actually, commit 57a6a72b made this change, and then 7bea19d0 backed it out again because it turned out to break things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: