Thanks Laurenz, for your help with debugging on this topic. I was preparing a message to the list myself and found an earlier discussion [1] on the topic. If I understand it correctly, the issue is with CREATE TABLE ... AS EXECUTE .... So it seems parallel execution of prepared statements was intentionally disabled in 7bea19d. However, what is missing is at least a mention of that current limitation in the 9.6 docs at "When Can Parallel Query Be Used?" [2]
Best regards, Tobias [1] https://www.postgresql.org/message-id/CA%2BTgmoaxyXVr6WPDvPQduQpFhD9VRWExXU7axhDpJ7jZBvqxfQ%40mail.gmail.com [2] https://www.postgresql.org/docs/current/static/when-can-parallel-query-be-used.html > Am 15.11.2016 um 16:41 schrieb Albe Laurenz <laurenz.a...@wien.gv.at>: > > 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. > > Yours, > Laurenz Albe > <0001-Consider-parallel-plans-for-statements-prepared-with.patch> > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
