to clarify. just trying to ensure I understand what PG 8.4 and 8.3 provide
where you may have data from alternate languages where ideally you'd like
them in the same table in the same database etc.
create table T ( c1 char( ...), c2 char (...) ... ) where c1 may contain
thai, c2 korean, c3 turkish
so where would I define something akin to what I can do in DB2 LUW where
collate using system means to sort by the codeset. ie. without english,
united states in LC_COLLATE.
USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM
On Mon, Dec 7, 2009 at 12:28 PM, Tom Lane wrote:
> the6campbells
the6campbells writes:
> Just want to clarify if there is something I've overlooked or if this is a
> known issue in PG 8.4 and 8.3
> CREATE DATABASE test
> WITH OWNER = postgres
>ENCODING = 'UTF8'
>LC_COLLATE = 'English, United States, UTF-8'
>LC_CTYPE = 'English, United
Just want to clarify if there is something I've overlooked or if this is a
known issue in PG 8.4 and 8.3
CREATE DATABASE test
WITH OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'English, United States, UTF-8'
LC_CTYPE = 'English, United States, UTF-8'
select ('İsteği')
Yes, the problem is the nested loop scan - it's scanning users 609070
times, which is awful.
Could you provide explain plan that executed fast? Was it executed with
the same parameter values or did the parameters change (maybe it's slow
for some parameters values only)?
Have you tried to rewrite
Hello List,
I have a query which use to run very fast now has turn into show stopper .
PostgreSQL:8.2
explain analyze select user_name,A.user_id, dnd_window_start, dnd_window_stop,
B.subs as subs, B.city_id as city_id, B.source_type as source_type from
