From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Steve McLellan" <smclellan(at)mintel(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query performance over a large proportion of data |
Date: | 2009-03-11 00:16:55 |
Message-ID: | 17476.1236730615@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Steve McLellan" <smclellan(at)mintel(dot)com> writes:
> lc_messages = 'en_US.UTF-8'
> lc_monetary = 'en_US.UTF-8'
> lc_numeric = 'en_US.UTF-8'
> lc_time = 'en_US.UTF-8'
BTW, aside from the points already made: the above indicates that you
initialized your database in en_US.utf8 locale. This is not necessarily
a good decision from a performance standpoint --- you might be much
better off with C locale, and might even prefer it if you favor
ASCII-order sorting over "dictionary" sorting. utf8 encoding might
create some penalties you don't need too. This all depends on a lot
of factors you didn't mention; maybe you actually need utf8 data,
or maybe your application doesn't do many string comparisons and so
isn't sensitive to the speed of strcoll() anyway. But I've seen it
be a gotcha for people moving from MySQL, which AFAIK doesn't worry
about honoring locale-specific sort order.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steve McLellan | 2009-03-11 03:15:13 | Re: Query performance over a large proportion of data |
Previous Message | Tom Lane | 2009-03-11 00:09:04 | Re: Query performance over a large proportion of data |