On Wed, Feb 17, 2016 at 6:41 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > Commit d1b7c1ffe72e86932b5395f29e006c3f503bc53d has added > the support for passing bind parameters to parallel workers, however > prepared statement which uses bind parameters wasn't enabled > for parallel query as the 'Execute' message in FE-BE protocol > can pass the row_count which can make parallel plans unusable. > (parallel plans are only possible when query can run to completion) > > Later Commit bfc78d7196eb28cd4e3d6c24f7e607bacecf1129 has > ensure that if the row_count is non-zero then we won't enter > parallel mode which means that even if parallel plan is selected > by optimizer, it will run such a plan locally. > > With above support, it was just a matter of enabling parallel > mode for prepared statements which is done in attached patch > (prepared_stmt_parallel_query_v1.patch). > > I have tested that parallel plans are getting generated both > via Prepare/Execute statements and libpq prepared > statement execution. Attached is a libpq program > (prepare_parallel_query.c) which I have used for testing prepared > statement support. I have done the verification manually > (using auto_explain) to ensure that parallel plans gets generated > and executed via this libpq program. This program expects some > data to be generated before-hand and the information of same is > added in file-header.
Hmm. I agree we should change exec_parse_message like this, but changing PrepareQuery seems wrong. I mean, there's a very good chance that a parse message will be followed by an Execute message with a zero row count, so we'll get parallel execution. But if the user says they want to PREPARE the query, they are probably not going to fetch all rows. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
