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:

Reply via email to