Re: More work on SortSupport for text - strcoll() and strxfrm() caching

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More work on SortSupport for text - strcoll() and strxfrm() caching
Date: 2015-10-08 18:37:01
Message-ID: CA+TgmoZe9FJAdcNjCk3aJcjwwGKVU1+sQzdG7nHGVo0dm04zOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 8, 2015 at 2:07 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Thu, Oct 8, 2015 at 10:13 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> It seems to me that (1) ABBREV_STRING_UINT isn't
>> a great name for this and (2) the comment is awfully long for the
>> thing to which it refers. I suggest that we instead call it
>> DatumToBigEndian(), put it pg_bswap.h, and change the comments to
>> something like this:
>>
>> /*
>> * Rearrange the bytes of a Datum into big-endian order.
>> *
>> * One possible application of this macro is to make comparisons
>> cheaper. An integer
>> * comparison of the new Datums will return the same result as a memcmp() on the
>> * original Datums, but the integer comparison should be much cheaper.
>> */
>>
>> The specific way that this is used by various sortsupport routines can
>> be adequately explained in the comments for those routines.
>
> This is pretty clearly something specific to SortSupport. I'm not
> opposed to changing the name and making the comments more terse along
> those lines, but I think it should live in sortsupport.h. The macro
> byteswaps datums on little-endian platforms only, which seems very
> specific.
>
> I think that we're going to have SortSupport with abbreviation for
> UUIDs and bytea at some point, and maybe character(n). Centralizing
> information about this to sortsupport.h makes sense to me.

I'm not convinced. Doesn't this exact same concept get used for
over-the-wire communication between BE and LE machines? There, this
operation is spelled htonl/ntohl. Some systems even have htonll, but
I'm sure there are still a bunch that don't.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-10-08 18:53:58 Re: proposal: PL/Pythonu - function ereport
Previous Message Oleg Bartunov 2015-10-08 18:09:43 Re: bugs and bug tracking