Re: a raft of parallelism-related bug fixes

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: a raft of parallelism-related bug fixes
Date: 2016-02-08 19:48:36
Message-ID: CAM3SWZTwTf3g4AVnM7hbat+nRQAnZYmTcM4hNwrGFOeoakGLoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 8, 2016 at 10:45 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> And, by the way, the patch, aside from the deadlock.c portion, was
> posted back in October, admittedly without much fanfare, but nobody
> reviewed that or any other patch on this thread. If I'd waited for
> those reviews to come in, parallel query would not be committed now,
> nor probably in 9.6, nor probably in 9.7 or 9.8 either. The whole
> project would just be impossible on its face. It would be impossible
> in the first instance if I did not have a commit bit, because there is
> just not enough committer bandwidth - even reviewer bandwidth more
> generally - to review the number of patches that I've submitted
> related to parallelism, so in the end some, perhaps many, of those are
> going to be committed mostly on the strength of my personal opinion
> that committing them is better than not committing them. I am going
> to have a heck of a lot of egg on my face if it turns out that I've
> been too aggressive in pushing this stuff into the tree. But,
> basically, the alternative is that we don't get the feature, and I
> think the feature is important enough to justify taking some risk.

FWIW, I appreciate your candor. However, I think that you could have
done a better job of making things easier for reviewers, even if that
might not have made an enormous difference. I suspect I would have not
been able to get UPSERT done as a non-committer if it wasn't for the
epic wiki page, that made it at least possible for someone to jump in.

To be more specific, I thought it was really hard to test parallel
sequential scan a few months ago, because there was so many threads
and so many dependencies. I appreciate that we now use git
format-patch patch series for complicated stuff these days, but it's
important to make it clear how everything fits together. That's
actually what I was thinking about when I said we need to be clear on
how things fit together from the CF app patch page, because there
doesn't seem to be a culture of being particular about that, having
good "annotations", etc.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-02-08 19:49:27 Re: a raft of parallelism-related bug fixes
Previous Message Fabien COELHO 2016-02-08 19:47:14 Re: extend pgbench expressions with functions