On Mon, Jun 20, 2016 at 4:52 PM, David G. Johnston
<david.g.johnston@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