Re: Parallel execution and prepared statements - Mailing list pgsql-hackers

From Tobias Bussmann
Subject Re: Parallel execution and prepared statements
Date
Msg-id DFF850D8-60E3-4185-B9B0-74726BB02682@gmx.net
Whole thread Raw
In response to Re: Parallel execution and prepared statements  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel execution and prepared statements  (Albe Laurenz <laurenz.albe@wien.gv.at>)
List pgsql-hackers
> I think if we don't see any impact then we should backpatch this
> patch. However, if we decide to go some other way, then I can provide
> a separate patch for back branches.  BTW, what is your opinion?

I could not find anything on backporting guidelines in the wiki but my opinion would be to backpatch the patch in
total.With a different behaviour between the simple and extended query protocol it would be hard to debug query
performanceissue in user applications that uses PQprepare. If the user tries to replicate a query with a PREPARE in
psqland tries to EXPLAIN EXECUTE it, the results would be different then what happens within the application. That
behaviourcould be confusing, like differences between EXPLAIN SELECT and EXPLAIN EXECUTE can be to less experienced
users.

Best regards
Tobias





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC.
Next
From: Noah Misch
Date:
Subject: Re: pgsql: Add putenv support for msvcrt from Visual Studio 2013