Horton

Re: Parallel execution and prepared statements

Tobias Bussmann <t.bussmann@gmx.net>

View thread
From: Tobias Bussmann <t.bussmann@gmx.net>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Cc: Albe Laurenz <laurenz.albe@wien.gv.at>, Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2016-11-17T15:07:00Z
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.

> Yeah, we could do something like this, perhaps not in exactly this
> way, but I'm not sure it's a good idea to just execute the parallel
> plan without workers.

sure, executing parallel plans w/o workers seems a bit of a hack. But:
- we already do it this way in some other situations
- the alternative in this special situation would be to _force_ replanning without the CURSOR_OPT_PARALLEL_OK. The decision for replanning is hidden deep within plancache.c and while we could influence it with CURSOR_OPT_CUSTOM_PLAN this wouldn't have an effect if the prepared statement doesn't have any parameters. Additionally, influencing the decision and generating a non-parallel plan would shift the avg cost calculation used to choose custom or generic plans.

Maybe someone can come up with a better idea for a solution. These three approaches are all I see so far.

Best regards,
Tobias Bussmann