public inbox for [email protected]  
help / color / mirror / Atom feed
Changing locale of an existing database
4+ messages / 2 participants
[nested] [flat]

* Changing locale of an existing database
@ 2025-06-17 16:20  Marcin Gozdalik <[email protected]>
  0 siblings, 1 reply; 4+ messages in thread

From: Marcin Gozdalik @ 2025-06-17 16:20 UTC (permalink / raw)
  To: pgsql-general

Hi

I am using PostgreSQL 17 and would like to take advantage of performance
and stability across OS updates of builtin C.UTF-8 locale.
I have a cluster with a DB created with en_US.UTF-8 libc locale. I would
like to migrate the DB to C.UTF-8. Ideally there'd be an "ALTER DATABASE
... SET LOCALE ..." command that would take care of it but it seems it
doesn't exist. I was thinking that I could change the collation of all
TEXT/CHAR/VARCHAR columns in all the tables to pg_c_utf8, REINDEX all those
columns and change the default locale in the pg_database table.

Is it a sensible plan? Am I missing some steps? I can't find any reference
to anybody doing that before or discouraging it.

Thanks,
Marcin

-- 
Marcin Gozdalik


^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: Changing locale of an existing database
@ 2025-06-17 16:55  Adrian Klaver <[email protected]>
  parent: Marcin Gozdalik <[email protected]>
  0 siblings, 1 reply; 4+ messages in thread

From: Adrian Klaver @ 2025-06-17 16:55 UTC (permalink / raw)
  To: Marcin Gozdalik <[email protected]>; pgsql-general

On 6/17/25 09:20, Marcin Gozdalik wrote:
> Hi
> 
> I am using PostgreSQL 17 and would like to take advantage of performance 
> and stability across OS updates of builtin C.UTF-8 locale.
> I have a cluster with a DB created with en_US.UTF-8 libc locale. I would 
> like to migrate the DB to C.UTF-8. Ideally there'd be an "ALTER DATABASE 
> ... SET LOCALE ..." command that would take care of it but it seems it 
> doesn't exist. I was thinking that I could change the collation of all 
> TEXT/CHAR/VARCHAR columns in all the tables to pg_c_utf8, REINDEX all 
> those columns and change the default locale in the pg_database table.
> 
> Is it a sensible plan? Am I missing some steps? I can't find any 
> reference to anybody doing that before or discouraging it.

How big a database are we talking about?

To me it would seem easier to create a new database with new locale and 
do either a pg_dump/pg_restore or logical replication to the new 
instance. Of course this may depend on the answer to the question above.

> 
> Thanks,
> Marcin
> 
> -- 
> Marcin Gozdalik

-- 
Adrian Klaver
[email protected]







^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: Changing locale of an existing database
@ 2025-06-17 17:30  Marcin Gozdalik <[email protected]>
  parent: Adrian Klaver <[email protected]>
  0 siblings, 1 reply; 4+ messages in thread

From: Marcin Gozdalik @ 2025-06-17 17:30 UTC (permalink / raw)
  To: Adrian Klaver <[email protected]>; +Cc: pgsql-general

Around 100 DBs, ranging from 1TB to 50TB.
Initial testing showed that it takes 1.5h to dump the DB and 3h to restore
it for a DB of around 3TB.

Just recreating the indexes takes around 30 minutes on the same DBs.

I understand that pg_dump/pg_restore is the safe route but it's too slow
for me so I'd like to understand if I have any alternative.


wt., 17 cze 2025 o 16:55 Adrian Klaver <[email protected]>
napisał(a):

> On 6/17/25 09:20, Marcin Gozdalik wrote:
> > Hi
> >
> > I am using PostgreSQL 17 and would like to take advantage of performance
> > and stability across OS updates of builtin C.UTF-8 locale.
> > I have a cluster with a DB created with en_US.UTF-8 libc locale. I would
> > like to migrate the DB to C.UTF-8. Ideally there'd be an "ALTER DATABASE
> > ... SET LOCALE ..." command that would take care of it but it seems it
> > doesn't exist. I was thinking that I could change the collation of all
> > TEXT/CHAR/VARCHAR columns in all the tables to pg_c_utf8, REINDEX all
> > those columns and change the default locale in the pg_database table.
> >
> > Is it a sensible plan? Am I missing some steps? I can't find any
> > reference to anybody doing that before or discouraging it.
>
> How big a database are we talking about?
>
> To me it would seem easier to create a new database with new locale and
> do either a pg_dump/pg_restore or logical replication to the new
> instance. Of course this may depend on the answer to the question above.
>
> >
> > Thanks,
> > Marcin
> >
> > --
> > Marcin Gozdalik
>
> --
> Adrian Klaver
> [email protected]
>
>

-- 
Marcin Gozdalik


^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: Changing locale of an existing database
@ 2025-06-17 21:01  Adrian Klaver <[email protected]>
  parent: Marcin Gozdalik <[email protected]>
  0 siblings, 0 replies; 4+ messages in thread

From: Adrian Klaver @ 2025-06-17 21:01 UTC (permalink / raw)
  To: Marcin Gozdalik <[email protected]>; +Cc: pgsql-general

On 6/17/25 10:30, Marcin Gozdalik wrote:
> Around 100 DBs, ranging from 1TB to 50TB.
> Initial testing showed that it takes 1.5h to dump the DB and 3h to 
> restore it for a DB of around 3TB.
> 
> Just recreating the indexes takes around 30 minutes on the same DBs.
> 
> I understand that pg_dump/pg_restore is the safe route but it's too slow 
> for me so I'd like to understand if I have any alternative.

Alright I see the issue. I don't know enough about this to say whether 
directly altering the system catalog would be a safe operation or not. 
An answer to that is going to need to come from someone with more 
knowledge on Postgres internals then I.



-- 
Adrian Klaver
[email protected]







^ permalink  raw  reply  [nested|flat] 4+ messages in thread


end of thread, other threads:[~2025-06-17 21:01 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-06-17 16:20 Changing locale of an existing database Marcin Gozdalik <[email protected]>
2025-06-17 16:55 ` Adrian Klaver <[email protected]>
2025-06-17 17:30   ` Marcin Gozdalik <[email protected]>
2025-06-17 21:01     ` Adrian Klaver <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox