Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
Дата
Msg-id 3666541.1694806930@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit  (Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>)
Ответы Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit  (Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>)
Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-performance
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



В списке pgsql-performance по дате отправления:

Предыдущее
От: Achilleas Mantzios
Дата:
Сообщение: Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
Следующее
От: Achilleas Mantzios
Дата:
Сообщение: Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit