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 18:19:35
Message-ID: 20140407181935.GJ4161@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-04-07 14:12:09 -0400, Stephen Frost wrote:
> 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.

There didn't seem to be any conflicts here? I am talking about
http://archives.postgresql.org/message-id/CAJTaR32A1_d0DqP25T4%3DLwE3RpmhNf3oY%3Dr0-ksejepfPv6O%3Dw%40mail.gmail.com

> > * Enable CREATE FOREIGN TABLE (... LIKE ... )
>
> This has definitely got issues which are not trival, see Tom's recent
> email on the subject..

Yea. Besides others, he confirmed my comments. The issue there was
basically that I didn't like something, others disagreed. Still needed a
committers input.

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

The minimal variant (just stddev) didn't seem to be all that
controversial.

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

I can understand that for feature patches which your company/client
needs, but for a localized performance improvement? Unconvinced.

And sorry, if the "threat of getting punted to the next release" plays
a significant role in here, the patch *needs* to be punted. The only
reason I can see at this point is "ah, trivial enough, let's just do
this now".

Greetings,

Andres Freund

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-04-07 18:19:57 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Stephen Frost 2014-04-07 18:17:42 Re: B-Tree support function number 3 (strxfrm() optimization)