On Mon, Jun 20, 2016 at 5:47 PM, Robert Haas <robertmh...@gmail.com> wrote:
> 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. > I don't. And I totally accept a response of: you are operating under a false premise here. My response above was more defensive that constructive. 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. I think my biggest (again, I'm not digging deep here) misunderstanding is testing mode versus production mode and what is or is not visible to the test framework compared to SQL/libpq 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. This is true - though I'd suspect not absolute. > 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?". > > This is a non-sequitur - or I'm just to worn to follow it. I did not intentionally set out to spend an hour of my own time to waste 20 minutes of yours. I won't apologize for an earnest attempt at self-education and contribution; no matter how badly it turned out. I will endeavor to learn from it and avoid similar errors in the future. David J.
