> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
