On Thu, Nov 17, 2016 at 10:07 AM, Tobias Bussmann <t.bussm...@gmx.net> wrote: >> 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
True, but we also try to avoid it whenever possible, because it's likely to lead to poor performance. > - 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers