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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
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 18:12:09
Message-ID: 20140407181209.GW4582@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> 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

I can take a look at that (if no one else wants to speak up about it).

> * Problem with displaying "wide" tables in psql

That's not without controvery, as I understand it, but I admit that I
haven't been following it terribly closely.

> * Enable CREATE FOREIGN TABLE (... LIKE ... )

This has definitely got issues which are not trival, see Tom's recent
email on the subject..

> * Add min, max, and stdev execute statement time in pg_stat_statement

This was also quite controversal. If we've finally settled on this as
being acceptable then perhaps it can get in pretty easily.

> * variant of regclass etc.

This was recently being discussed also.

> * vacuumdb: Add option --analyze-in-stages

Haven't looked at this at all.

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

That strikes me as optimistic. I do plan to go do another pass through
the commitfest patches before looking at other things (as Greg also said
he would do); thanks for bringing up the ones you feel are more
managable- it'll help me focus on them.

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

This would be another case where it'd be nice if we could give people
access to the buildfarm w/o having to actually commit something.

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

There wouldn't be any discussion if it was CF-1 as I doubt anyone would
object to it going in (or at least not as strongly..), even if it was
submitted after CF-1 was supposed to be over with remaining patches.
It's the threat of getting punted to the next release that really makes
the difference here, imv.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-07 18:12:24 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Fabrízio de Royes Mello 2014-04-07 18:08:54 Re: Firing trigger if only