From: Tom Lane <tgl@sss.pgh.pa.us>
To: Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
cc: pgsql-performance@lists.postgresql.org
Subject: Re: pgsql 10.23 , different systems, same table , same plan,
 different Buffers: shared hit
In-reply-to: <ce9acb4c-aa59-32b6-44fd-cfe713a4bf5c@cloud.gatewaynet.com>
References: <24a36ca8-b5c0-d39f-c5f6-47cf2ef51abd@cloud.gatewaynet.com>
 <3310210.1694791429@sss.pgh.pa.us>
 <ce9acb4c-aa59-32b6-44fd-cfe713a4bf5c@cloud.gatewaynet.com>
Comments: In-reply-to Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
	message dated "Fri, 15 Sep 2023 22:31:37 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3666540.1694806930.1@sss.pgh.pa.us>
Date: Fri, 15 Sep 2023 15:42:10 -0400
Message-ID: <3666541.1694806930@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3666541.1694806930%40sss.pgh.pa.us>
Precedence: bulk

Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com> writes:
> Thank you, I see that both systems use en_US.UTF-8 as lc_collate and 
> lc_ctype,

Doesn't necessarily mean they interpret that the same way, though :-(

> the below seems ok

> FreeBSD :

> postgres@[local]/dynacom=# select * from (values 
> ('a'),('Z'),('_'),('.'),('0')) as qry order by column1::text;
> column1
> ---------
> _
> .
> 0
> a
> Z
> (5 rows)

Sadly, this proves very little about Linux's behavior.  glibc's idea
of en_US involves some very complicated multi-pass sort rules.
AFAICT from the FreeBSD sort(1) man page, FreeBSD defines en_US
as "same as C except case-insensitive", whereas I'm pretty sure
that underscores and other punctuation are nearly ignored in
glibc's interpretation; they'll only be taken into account if the
alphanumeric parts of the strings sort equal.

			regards, tom lane