Στις 16/9/23 02:08, ο/η Thomas Munro έγραψε:
On Sat, Sep 16, 2023 at 7:42 AM Tom Lane wrote:
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 "sa
On Sat, Sep 16, 2023 at 7:42 AM Tom Lane wrote:
> 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", wherea
Στις 15/9/23 22:42, ο/η Tom Lane έγραψε:
Achilleas Mantzios 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 (valu
Achilleas Mantzios 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'),('_'),('.'),('
Στις 15/9/23 18:23, ο/η Tom Lane έγραψε:
Achilleas Mantzios - cloud writes:
*FreeBSD*
-> Index Only Scan using mail_vessel_addressbook_address_regex_idx
on mail_vessel_addressbook (cost=0.42..2912.06 rows=620 width=32)
(actual time=96.704..96.705 rows=1 loops=1)
Filter: ('f...@
Achilleas Mantzios - cloud writes:
> *FreeBSD*
>
>-> Index Only Scan using mail_vessel_addressbook_address_regex_idx
> on mail_vessel_addressbook (cost=0.42..2912.06 rows=620 width=32)
> (actual time=96.704..96.705 rows=1 loops=1)
> Filter: ('f...@bar.com'::text ~* address_regex)
Dear All
I have a weird problem, I am trying to improve performance on this query :
SELECT text('f...@bar.com') from mail_vessel_addressbook where
text('f...@bar.com') ~* address_regex limit 1;
The first system (linux) is a linux hosted in a cloud, kernel
3.16.0-4-amd64, 32GB mem, SSD, 4 x I
On 2023-Sep-14, bruno da silva wrote:
> This problem is more acute when the FK Table stores a small number of rows
> like types or codes.
Right, because the likelihood of multiple transactions creating
new references to the same row is higher.
> I think in those cases an enum type should be used
