Привет! Кто как измеряет cache hit файлового кеша ос?

параметры базы данных LC_COLLATE и LC_CTYPE невозможно изменить после её создания

Понял.. Значит pg_upgrade мне не светит 🙁 Только dump/restore

Хмм... а зачем?

ну, как минимум, нормально не работет сортировка кириллицы.

и pg_upgrade ругается lc_collate values for database "postgres" do not match:  old "C", new "en_US.utf8"
Failure, exiting

Я для полей из JSONB активно участвующих в запросах сделал generated column.
И работает быстрее, и можно их в индексы добавлять

А, понятно (я просто подумал, раз это существующая БД — "но сейчас-то всё работает" ;) ).
Кстати, если это база, где есть много текстовых полей, для которых порядок сортировки всего, что не ascii, в общем-то, не важен — об установке LC_COLLATE=С для базы, а потом нужного collation только для полей, где это нужно, можно всерьёз подумать.

Спасибо)

Это обусловлено дальнейшим гемором использования... Collate=C тянется еще с незапамятных времен pg-7.4.... сейчас при переходе с 9.2 на 12.3 нужно это нужно исправить... Потому что текстовых полей очень много и в каждом прописывать collate - гемор

Ну да, если их много, то это того не стоит.
И Вам придётся делать dump / restore, конечно.

dump/restore очень медленный 🙁 pg_upgrade отрабатывал за 10 минут, эта связка около часа будет пыхтеть... И потом еще vacuum analyze минут 20.... много времени теряется, а система очень критична к простоям...

А что поделаешь. :(
Можно с помощью какой-нибудь триггерной репликации (вроде Slony) попробовать мигрировать... но Вам вряд ли этого на самом деле захочется. ;)

> эта связка около часа будет пыхтеть...

Это Вы проверяли на тестовом кластере (потому что 10 минут — это как-то много для "настоящего" (--link) pg_upgrade (в среднем))?

> vacuum analyze минут 20...

Есть vacuumdb --analyze-in-stages — может, этого будет достаточно (т.е. производительность будет терпимой)?

У меня есть восстановленый дамп на 10.13. через pg_upgrade мигрировал на 12.3.... 10 минут... Но с 9.2 на 12.3 не получается из-за разных collation. dump на 10.13 восстанавливается минут около 40. Ну и дампится минут 20

vacuum analyze то не блокирует работу, но производительность несколько просаживает... Хотя это и не критично по большому счету, конечно

да и на 9.2 с pg_ctl есть проблемы, хотя и решаемые... В общем придется мигрировать самым отстойным вариантом

Вопросик.... при pg_restore есть ключик -j. Его по количеству ядер или по количеству потоков выставлять? Стоит Xeon E5-1630 v3 на 4 ядра / 8 потоков

Опять-таки, 10 минут — странновато, но у Вас, наверное, много таблиц.
pg_upgrade -k с разными default collation всё равно не получится (это "физически" невозможно), поэтому можно сразу мигрировать дампами с 9.2 на 12.3.
Вообще, можно временно настроить 12.3 на максимальную производительность (вообще с расчётом на то, что за время upgrade проблем не будет) для загрузки дампов (это может существенно сократить время), а потом перезапустить уже в нормальном режиме.

Да лучше Вы сразу прочитайте https://www.postgresql.org/docs/current/populate.html , IMHO.
А потом найдите самый быстрый вариант (у Вас же есть тестовые данные).
И я бы начинал не с:

> У меня есть восстановленый дамп на 10.13

А сразу снимал дампы с 9.2, "как положено" (т.е. pg_dumpall / pg_dump из 12.3) и т.п.

У меня просто несколько поднято их.... Думал сначала на 10-ку мигрировать.... Но потом посмотрел и решил на 12.3... Сейчас проверяем стабильность работы софта на 12.3 и, если все ок, перейдем наверное на него