On Fri, Dec 19, 2014 at 9:39 AM, Stephen Frost <sfr...@snowman.net> wrote: > Perhaps we should reconsider our general position on hints then and > add them so users can define the plan to be used.. For my part, I don't > see this as all that much different. > > Consider if we were just adding HashJoin support today as an example. > Would we be happy if we had to default to enable_hashjoin = off? Or if > users had to do that regularly because our costing was horrid? It's bad > enough that we have to resort to those tweaks today in rare cases.
If you're proposing that it is not reasonable to have a GUC that limits the degree of parallelism, then I think that's outright crazy: that is probably the very first GUC we need to add. New query processing capabilities can entail new controlling GUCs, and parallelism, being as complex at it is, will probably add several of them. But the big picture here is that if you want to ever have parallelism in PostgreSQL at all, you're going to have to live with the first version being pretty crude. I think it's quite likely that the first version of parallel sequential scan will be just as buggy as Hot Standby was when we first added it, or as buggy as the multi-xact code was when it went in, and probably subject to an even greater variety of taxing limitations than any feature we've committed in the 6 years I've been involved in the project. We get to pick between that and not having it at all. I'll take a look at the papers you sent about parallel query optimization, but personally I think that's putting the cart not only before the horse but also before the road. For V1, we need a query optimization model that does not completely suck - no more. The key criterion here is that this has to WORK. There will be time enough to improve everything else once we reach that goal. -- 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
