Re: Prepared Statement support for Parallel query

On Wed, Feb 17, 2016 at 6:41 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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