Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CA+TgmoZNNsfu-yx-X5t-+K2tatGXrCgs-BHwWGJQx9Kh8R=8fg@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Tue, Nov 25, 2014 at 1:38 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Tue, Nov 25, 2014 at 4:01 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> - This appears to needlessly reindent the comments for PG_CACHE_LINE_SIZE.
>
> Actually, the word "only" is removed (because PG_CACHE_LINE_SIZE has a
> new client now). So it isn't quite the same paragraph as before.

Oy, I missed that.

>> - I really don't think we need a #define in pg_config_manual.h for
>> this.  Please omit that.
>
> You'd prefer to not offer a way to disable abbreviation? Okay. I guess
> that makes sense - it should work well as a general optimization.

I'd prefer not to have a #define in pg_config_manual.h.  Only stuff
that we expect a reasonably decent number of users to need to change
should be in that file, and this is too marginal for that.  If anybody
other than the developers of the feature is disabling this, the whole
thing is going to be ripped back out.

> I'm not sure about that. I'd prefer to have tuplesort (and one or two
> other sites) set the "abbreviation is possible in principle" flag.
> Otherwise, sortsupport needs to assume that the leading attribute is
> going to be the abbreviation-applicable one, which might not always be
> true. Still, it's not as if I feel strongly about it.

When wouldn't that be true?

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Turning recovery.conf into GUCs
Next
From: Emre Hasegeli
Date:
Subject: Re: Selectivity estimation for inet operators