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
prepared_stmt_parallel_query_v1.patch
Description: Binary data
/*
* Test case for PreparedStmt
* Need first to run this query on the database connection is made
* to:
* CREATE TABLE t1 (c1 int, c2 char(1000));
* INSERT INTO t1 values(generate_series(1,500000), 'aaaa');
*/
#include <libpq-fe.h>
#define DB_CONN_STR "host=localhost dbname=postgres"
#define SQL_FETCH_AA "select c1 from t1 where c1 < $1"
int
main(int argc, char *argv[])
{
PGconn* conn;
PGresult* res;
int ntuples;
const char* paramValues[1];
if ((conn = PQconnectdb(DB_CONN_STR)) == NULL)
fprintf(stderr, "Connect to '%s' failed", DB_CONN_STR);
if (PQstatus(conn) != CONNECTION_OK)
fprintf(stderr, "Connect to '%s' failed: %s",
DB_CONN_STR, PQerrorMessage(conn));
if ((res = PQprepare(conn, "sql_fetch_aa",
SQL_FETCH_AA, 1, NULL)) == NULL)
fprintf(stderr, "Preparing statement '%s' failed",
SQL_FETCH_AA);
if (PQresultStatus(res) != PGRES_COMMAND_OK)
fprintf(stderr, "Preparing statement '%s' failed: %s",
SQL_FETCH_AA, PQerrorMessage(conn));
paramValues[0] = "1000";
res = PQexecPrepared(conn, "sql_fetch_aa", 1,
paramValues,
NULL, NULL, 0);
if (PQresultStatus(res) != PGRES_TUPLES_OK)
{
fprintf(stderr, "fetch data failed: %s",
PQerrorMessage(conn));
return 1;
}
ntuples = PQntuples(res);
PQclear(res);
PQfinish(conn);
return 0;
}
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
