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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Thom Brown <thom(at)linux(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Date: 2014-04-07 17:54:45
Message-ID: 20140407175445.GI4161@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-04-07 13:01:52 -0400, Stephen Frost wrote:
> I haven't got any either (except for my little one), which frustrates
> me greatly. Not because I'm looking for credit on the time that I've
> spent in discussions, doing reviews, and I could have sworn there was
> some patch that I did commit, but because I've not been able to find
> the larger chunks of time required to get the more complex patches in.

I am a bit confused. To my eyes there's been a huge number of actually
trivial patches in this commitfest? Even now, there's some:

* Bugfix for timeout in LDAP connection parameter resolution
* Problem with displaying "wide" tables in psql
* Enable CREATE FOREIGN TABLE (... LIKE ... )
* Add min, max, and stdev execute statement time in pg_stat_statement
* variant of regclass etc.
* vacuumdb: Add option --analyze-in-stages

Are all small patches that don't need major changes before getting committed.

That's after three months. And after a high number of smaller patches
committed by Tom on Friday.

> > When a committer says, hey, I'm going to commit XYZ, that
> > basically forces anybody who might have an objection to it to drop
> > what they're doing and object fast, before it's too late. In other
> > words, the people who just said that they are too busy reviewing
> > patches that were timely submitted and don't want to divert effort
> > from that to handle patches that weren't are going to have to do that
> > anyway, or lose their right to object.
>
> I don't agree that this is the case. We do revert patches from time to
> time, when necessary, and issues with this particular patch seem likely
> to be found during testing, well in advance of any release, and it's
> self contained enough to be reverted pretty easily.

Given the trackrecord with testing the project seems to have with
testing, I don't have much faith in that claim. But even if, it'll only
get you testing on 2-3 platforms, without noticing portability issues.

I think it'd be a different discussion if this where CF-1 or so. But
we're nearly *2* months after the the *end* of the last CF.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-04-07 17:58:35 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Robert Haas 2014-04-07 17:47:25 Re: B-Tree support function number 3 (strxfrm() optimization)