Re: Prepared Statement support for Parallel query

On Wed, Feb 24, 2016 at 7:27 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> 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.

Yes and I think libpq doesn't even provide a interface to specify row
count for prepared statements.

> But if the user says
> they want to PREPARE the query, they are probably not going to fetch
> all rows.
>
>
After PREPARE, user will execute the statement using EXECUTE and
I don't see how user can decide number of rows to fetch which can
influence the execution. Can you please elaborate your point more
and what is your expectation for the same?

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