On Thu, Jan 11, 2018 at 1:44 PM, Robert Haas <robertmh...@gmail.com> wrote: >> A third option here is to specifically recognize that >> compute_parallel_worker() returned a value based on the table storage >> param max_workers, and for that reason alone no "insufficient memory >> per participant" decrementing/vetoing should take place. That is, when >> the max_workers param is set, perhaps it should be completely >> impossible for CREATE INDEX to ignore it for any reason other than an >> inability to launch parallel workers (though that could be due to the >> max_parallel_workers GUC's setting). >> >> You could argue that we should do this anyway, I suppose. > > Yes, I think this sounds like a good idea.
Cool. I've already implemented this in my local working copy of the patch. That settles that. If I'm not mistaken, the only outstanding question at this point is whether or not we're going to give in and completely remove parallel leader participation entirely. I suspect that we won't end up doing that, because while it's not very useful, it's also not hard to support. Besides, to some extent that's the expectation that has been established already. I am not far from posting a revision that incorporates all of your feedback. Expect that tomorrow afternoon your time at the latest. Of course, you may have more feedback for me in the meantime. Let me know if I should hold off on posting a new version. -- Peter Geoghegan
