On Mon, Jun 20, 2016 at 4:52 PM, David G. Johnston <david.g.johns...@gmail.com> wrote: > Internal or external I do think the number and type of flags described here, > for the purposes described, seems undesirable from an architectural > standpoint.
Well, that seems like a bold statement to me, because I think that one really has to understand why flags got added before deciding whether there are too many of them, and it's not clear to me that you do. What we're talking about here is ONE flag, which currently controls whether the leader will participate in running Gather's child plan. What happens when the flag is set to "leader should not participate" and no workers are available? The current behavior is that the leader runs the plan in lieu of the workers, and Tom is proposing to change it so that we wait for a worker to become available instead. That has the advantage of being better for testing, but the disadvantage of being possibly less useful for other purposes. Neither of us are proposing to eliminate the flag, which would only serve to cripple test coverage, and I will venture to say that neither Tom nor anyone else who has spent much time looking at the way any part of the system works would argue that a Node type with ONE flag has too many flags. I am usually quite happy when people other than senior hackers weigh in on threads here, especially about user-visible behavior, because senior hackers can be quite myopic. We spend most of our time developing the system rather than using it, and sometimes our notion of what is useful or acceptable is distorted because of it. Moreover, none of us are so smart that we can't be wrong, so a gut check from somebody else is often helpful. But, of course, an opinion that proceeds from a false premise doesn't provide useful guidance. Many people realize this, which is why we tend to get entirely too many opinions on questions like "should we change the version number?" and far too few on questions like "how should we refactor heap_update?". -- 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
