Re: Parallel execution and prepared statements
Tobias Bussmann <t.bussmann@gmx.net>
From: Tobias Bussmann <t.bussmann@gmx.net>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>,
Albe Laurenz <laurenz.albe@wien.gv.at>,
Amit Kapila <amit.kapila16@gmail.com>
Date: 2016-11-21T15:11:51Z
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 →
-
Enable parallelism for prepared statements and extended query protocol.
- 57a6a72b6bc9 9.6.0 cited
> True, but we also try to avoid it whenever possible, because it's > likely to lead to poor performance. This non-readonly case should be way less often hit compared to other uses of prepared statements. But sure, it depends on the individual use case and a likely performance regession in these edge cases is nothing to decide for easily. > I think it would be a good idea to come up with a way for a query to > produce both a parallel and a non-parallel plan and pick between them > at execution time. However, that's more work than I've been willing > to undertake. Wouldn't the precautionary generation of two plans always increase the planning overhead, which precisely is what one want to reduce by using prepared statements? Best regards Tobias