| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Achilleas Mantzios <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)com> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit |
| Date: | 2023-09-15 19:42:10 |
| Message-ID: | 3666541.1694806930@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Achilleas Mantzios <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)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(at)[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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Achilleas Mantzios | 2023-09-15 20:36:48 | Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit |
| Previous Message | Achilleas Mantzios | 2023-09-15 19:31:37 | Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit |