| From: | Tobias Bussmann <t(dot)bussmann(at)gmx(dot)net> |
|---|---|
| To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: Parallel execution and prepared statements |
| Date: | 2016-12-03 17:42:21 |
| Message-ID: | DFF850D8-60E3-4185-B9B0-74726BB02682@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 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.
Best regards
Tobias
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joseph Brenner | 2016-12-03 20:08:30 | Select works only when connected from login postgres |
| Previous Message | Tom Lane | 2016-12-03 16:43:02 | Re: [COMMITTERS] pgsql: Add max_parallel_workers GUC. |