You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Allow for parallel execution whenever ExecutorRun() is done only once.
Previously, it was unsafe to execute a plan in parallel ifExecutorRun() might be called with a non-zero row count. However,it's quite easy to fix things up so that we can support that case,provided that it is known that we will never call ExecutorRun() asecond time for the same QueryDesc. Add infrastructure to signalthis, and cross-checks to make sure that a caller who claims this istrue doesn't later reneg.While that pattern never happens with queries received directly from aclient -- there's no way to know whether multiple Execute messageswill be sent unless the first one requests all the rows -- it's prettycommon for queries originating from procedural languages, which oftenlimit the result to a single tuple or to a user-specified number oftuples.This commit doesn't actually enable parallelism in any additionalcases, because currently none of the places that would be able tobenefit from this infrastructure pass CURSOR_OPT_PARALLEL_OK in thefirst place, but it makes it much more palatable to passCURSOR_OPT_PARALLEL_OK in places where we currently don't, because iteliminates some cases where we'd end up having to run the parallelplan serially.Patch by me, based on some ideas from Rafia Sabih and corrected byRafia Sabih based on feedback from Dilip Kumar and myself.Discussion:http://postgr.es/m/CA+TgmobXEhvHbJtWDuPZM9bVSLiTj-kShxQJ2uM5GPDze9fRYA@mail.gmail.com