Prepared Statement support for Parallel query - Mailing list pgsql-hackers

From Amit Kapila
Subject Prepared Statement support for Parallel query
Date
Msg-id CAA4eK1L=tHmmHDK_KW_ja1_dusJxJF+SGQHi=APS4MdNPk7HFQ@mail.gmail.com
Whole thread Raw
Responses Re: Prepared Statement support for Parallel query
Re: Prepared Statement support for Parallel query
List pgsql-hackers
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.

Thoughts?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: proposal: function parse_ident
Next
From: Artur Zakirov
Date:
Subject: Re: [PROPOSAL] Improvements of Hunspell dictionaries support