On Mon, Apr 3, 2017 at 4:17 PM, Andres Freund <and...@anarazel.de> wrote: > Hm. I'm not really convinced by the logic here. Wouldn't it be better > to try to compute the minimum total cost across all workers for > 1..#max_workers for the plans in an iterative manner? I.e. try to map > each of the subplans to 1 (if non-partial) or N workers (partial) using > some fitting algorith (e.g. always choosing the worker(s) that currently > have the least work assigned). I think the current algorithm doesn't > lead to useful #workers for e.g. cases with a lot of non-partial, > high-startup plans - imo a quite reasonable scenario.
Well, that'd be totally unlike what we do in any other case. We only generate a Parallel Seq Scan plan for a given table with one # of workers, and we cost it based on that. We have no way to re-cost it if we changed our mind later about how many workers to use. Eventually, we should probably have something like what you're describing here, but in general, not just for this specific case. One problem, of course, is to avoid having a larger number of workers always look better than a smaller number, which with the current costing model would probably happen a lot. -- 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
