Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id 20140407183523.GZ4582@tamriel.snowman.net
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> That's why we have this rule that CF4 should only receive patches that
> were already reviewed in previous commitfests.

I, at least, always understood that rule to be 'large' patches, which
this didn't strike me as.

> I, too, find the
> fast-tracking of this patch completely outside of the CF process to be
> distasteful.  We summarily reject much smaller patches at the end of
> each cycle process, even when the gain is as obvious as is claimed to
> be for this patch.

In the past, we've also committed large patches which were submitted for
the first time to CF-4.

> TBH I don't see why we're even discussing this.

Think I'm about done, personally.  I can't comment more without actually
looking at it and doing some research on it myself and I don't know that
I'll be able to do that any time soon, as I told Peter when he asked me
about it in NYC.  That said, for my part, I don't like telling Greg that
he either has to review something else which was submitted but that he's
got no interest in (or which would take much longer), or not do
anything.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Next
From: Andres Freund
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)