Re: B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 1:01 PM, Stephen Frost <sfrost@snowman.net> wrote:
> All that said, I don't have any particularly good idea of how to "fix"
> any of this- it's not fair to tell the committers who have more time (or
> larger blocks of time, etc) "you must work the hard problems only"
> either.  I don't feel Greg's interest in this patch has anything to do
> with his current employment and everything to do with the side-talks in
> NYC, and to that point, I'm very tempted to go look at this patch myself
> because it sounds like an exciting improvement with minimal effort.
> Would I feel bad for doing so, with the CustomScan API and Updatable
> Security Barrier Views patches still pending?  Sure, but it's the
> difference between finding an hour and finding 8.  The hour will come
> pretty easily (probably spent half that on this email..), while an
> 8-hour block, which would likely turn into more, is neigh-on impossible
> til at least this weekend.  And, no, 8x one-hour blocks would not be
> worthwhile; I've tried that before.

If it's only going to take you an hour to address this patch (or 8 to
address those other ones) then you spend a heck of a lot less time on
review for a patch of a given complexity level than I do.  I agree
that it's desirable to slip things in, from time to time, when they're
uncontroversial and obviously meritorious, but I'm not completely
convinced that this is such a case.  As an utterly trivial point, I
find the naming to be less than ideal: "poorman" is not a term I want
to enshrine in our code.  That's not very descriptive of what the
patch is actually doing even if you know what the idiom means, and
people whose first language - many of whom do significant work on our
code - may not.

Now the point is not that that's a serious flaw in and of itself.  The
point is that these kinds of issues deserve to be discussed and agreed
on, and the process should be structured in a way that permits that.
And that discussion will require the time not only of the people who
find this patch more interesting than any other, but also of the
people who just said that they're busy with other things right now,
unless those people want to forfeit their right to an opinion.
Experience has shown that it's a whole lot easier for anyone here to
get a patch changed before it's committed than after it's committed,
so I don't buy your argument that the timing there doesn't matter.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company