On Tue, Sep 23, 2014 at 7:35 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Would this person be it an extra committer or an simple reviewer? It
> would give more insurance if such huge patches (couple of thousands of
> lines) get an extra +1 from another committer, proving that the code
> has been reviewed by people well-experienced with backend code. Now as
> this would put more pressure in the hands of committers, an extra
> external pair of eyes, be it non-committer but let's say a seasoned
> reviewer would be fine IMO.
If you're volunteering, I certainly wouldn't say "no". The more the
merrier. Same with anyone else. Since Heikki looked at it before, I
also think it would be appropriate to give him a bit of time to see if
he feels satisfied with it now - nobody on this project has more
experience with indexing than he does, but he may not have the time,
and even if he does, someone else might spot something he misses.
Alvaro's quite right to point out that there is no sense in waiting a
long time for a review that isn't coming. That just backs everything
up against the end of the release cycle to no benefit. But if there's
review available from experienced people within the community, taking
advantage of that now might find things that could be much harder to
fix later. That's a win for everybody. And it's not like we're
pressed up against the end of the cycle, nor is it as if this feature
has been through endless rounds of review already. It's certainly had
some, and it's gotten better as a result. But it's also changed a lot
in the process.
And much of the review to date has been high-level design review, like
"how should the opclasses look?" and "what should we call this thing
anyway?". Going through it for logic errors, documentation
shortcomings, silly thinkos, etc. has not been done too much, I think,
and definitely not on the latest version. So, some of that might not
be out of place.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company