On Monday, February 8, 2016, Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2016-02-08 16:07:05 -0500, Robert Haas wrote: > > One of the questions I have about parallel query is whether it should > > be enabled by default. That is, should we make the default value of > > max_parallel_degree to a value higher than 0? Perhaps 1, say? > > > > There are some good reasons why this might be a bad idea, such as: > > > > - As discussed on a nearby thread, there is every possibility of nasty > > bugs. > > I think that's an argument to enable it till at least beta1. Let's > change the default, and add an item to the open items list to reconsider > then. > > I'd rather phrase that as: I cannot think of any reason to not make it on by default so let's do so until experience tells us differently. If experience says it is too buggy then I'd be concerned about allowing it be to enabled at all let alone by default. If there are usage concerns then ideally the postmaster could detect them and configure itself rather than provide yet another knob for people to research. I don't know enough about the specifics on that end myself. IOW I could not convince myself that the end of beta was somehow important to this decision - but maybe the hash join bug has me soured... As a user I'd like it to just work within the confines of what system resources I've told PostgreSQL as a whole it can use and that it detects it has available to it by asking the O/S. So, for me the quality of the feature is a on/off decision and not a "defaults" one. the argument that our default configuration is geared toward low resource setups and since this is resource intensive it should be disabled resonates though I'd rather it work reasonably (of self toggle off) in both low and large resource environments. Is that possible? David J.
