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
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) |