Re: More work on SortSupport for text - strcoll() and strxfrm() caching - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: More work on SortSupport for text - strcoll() and strxfrm() caching
Date
Msg-id CAM3SWZQ3hdqNUkdbwepmp-4ixoGEMUq=2-BxMFRz5LXOv4BzRw@mail.gmail.com
Whole thread Raw
In response to Re: More work on SortSupport for text - strcoll() and strxfrm() caching  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: More work on SortSupport for text - strcoll() and strxfrm() caching
List pgsql-hackers
On Thu, Oct 8, 2015 at 10:13 AM, Robert Haas <robertmhaas@gmail.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.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Oleg Bartunov
Date:
Subject: Re: bugs and bug tracking