Horton

Re: Parallel execution and prepared statements

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Albe Laurenz <laurenz.albe@wien.gv.at>
Cc: "Tobias Bussmann *EXTERN*" <t.bussmann@gmx.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2016-12-06T16:46:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Enable parallelism for prepared statements and extended query protocol.

On Mon, Dec 5, 2016 at 5:18 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
> Tobias Bussmann wrote:
>>> 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 performance issue in user applications that uses PQprepare. If the user tries
>> to replicate a query with a PREPARE in psql and tries to EXPLAIN EXECUTE it, the results would be
>> different then what happens within the application. That behaviour could be confusing, like
>> differences between EXPLAIN SELECT and EXPLAIN EXECUTE can be to less experienced users.
>
> +1

Done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company