AL
скорей всего user time, т.к. постройка индекса оно обычно в проц упирается... сортировка же
Size: a a a
2021 February 08
b
скорей всего user time, т.к. постройка индекса оно обычно в проц упирается... сортировка же
Linux 4.15.0-29-generic (b05) 02/08/2021 _x86_64_ (24 CPU)
06:26:08 AM UID PID %usr %system %guest %wait %CPU CPU Command
06:26:08 AM 1000 5456 0.30 0.00 0.00 0.00 0.31 9 postgresВот такое вот показывает, а CPU почему-то каждый раз новый. Почему он с ядра на ядро прыгает, это нормально?
AL
запустите так pidstat -u -p 5456 1
YS
Ох блин, копирую я таблицу
email_address, и оказывается что оно обновляет индекс ix_email_address_domain_id! Разве COPY это должен делать? Или оно COPY только на стороне отправителя, а на логическую реплику оно прилетает в виде единичных операций внутри гигантской трансакции?> Разве COPY это должен делать?
Разумеется. Любой COPY делает это, и вообще любая обычная запись.
COPY быстр только за счёт того, что у него overhead на обработку входных данных куда меньше, чем у других методов, вот и всё. ;)
Разумеется. Любой COPY делает это, и вообще любая обычная запись.
COPY быстр только за счёт того, что у него overhead на обработку входных данных куда меньше, чем у других методов, вот и всё. ;)
AL
то что прыгает это ок, это планировщик ядра так планиирует работу процессов в многозадачной ОС
b
AL
ну вот да, user time в полку, соотв. и читает с диска мало потому что некогда ))) надо вычисления вычислять
b
Yaroslav Schekin
> Разве COPY это должен делать?
Разумеется. Любой COPY делает это, и вообще любая обычная запись.
COPY быстр только за счёт того, что у него overhead на обработку входных данных куда меньше, чем у других методов, вот и всё. ;)
Разумеется. Любой COPY делает это, и вообще любая обычная запись.
COPY быстр только за счёт того, что у него overhead на обработку входных данных куда меньше, чем у других методов, вот и всё. ;)
Мне казалось что например импорт бекапа обычно сначала закидывает данные, и только потом создает индексы. Таким образом, в среднем по больнице, при построении индекса лучше сохраняется локальность кеша того что там фактически индексируется.
b
Ну при импорте бекапа я понимаю что это pg_dump выкладывает команды в определенной последовательности, но с логической репликацией DDL мы делаем сами. Все понятно 🙂
AL
вы наверно когда переносили схему таблицы, сразу и индексы создались (пустые), так вот при copy они также и наполняются...
а при ресторе из бэкапа, данные люьтся в пустую таблицу без индексов. и только потом индексы строятся уже отдельно
а при ресторе из бэкапа, данные люьтся в пустую таблицу без индексов. и только потом индексы строятся уже отдельно
YS
Мне казалось что например импорт бекапа обычно сначала закидывает данные, и только потом создает индексы. Таким образом, в среднем по больнице, при построении индекса лучше сохраняется локальность кеша того что там фактически индексируется.
> например импорт бекапа обычно сначала закидывает данные
Дампа, в смысле? Да, но только потому, что в дампе явно написано примерно следующее:
Дампа, в смысле? Да, но только потому, что в дампе явно написано примерно следующее:
CREATE TABLE x(...);
COPY x FROM ...
CREATE INDEX x_index_1 ON x (...);
CREATE INDEX x_index_2 ON x (...);
...
YS
Ну при импорте бекапа я понимаю что это pg_dump выкладывает команды в определенной последовательности, но с логической репликацией DDL мы делаем сами. Все понятно 🙂
Да, не стоило все индексы сразу создавать, скорее всего.
Хватило бы и таблицы / replica identity index, а уж после можно было бы создать остальные, так было бы быстрее.
Хватило бы и таблицы / replica identity index, а уж после можно было бы создать остальные, так было бы быстрее.
b
Yaroslav Schekin
> например импорт бекапа обычно сначала закидывает данные
Дампа, в смысле? Да, но только потому, что в дампе явно написано примерно следующее:
Дампа, в смысле? Да, но только потому, что в дампе явно написано примерно следующее:
CREATE TABLE x(...);
COPY x FROM ...
CREATE INDEX x_index_1 ON x (...);
CREATE INDEX x_index_2 ON x (...);
...
Угу, вот я это и имел ввиду. Все понятно, теперь при таких маневрах буду делать DDL вручную и добавлять индексы только после изначальной COPY.
АШ
Доброго дня. Я случайно восстановил базу из sql-дампа два раза, и данные задвоились. Есть ли какой то способ это исправить?
LS
Коллеги, обязательно ли держать одинаковыми конфиги MASTER AND SLAVE ? Кроме той части которая за репликацию отвечает.
R
Коллеги, обязательно ли держать одинаковыми конфиги MASTER AND SLAVE ? Кроме той части которая за репликацию отвечает.
только ряд параметров обязательны, в остальном нет
LS
только ряд параметров обязательны, в остальном нет
А я могу логирование log_statement=all сделать только на Slave ?
R
А я могу логирование log_statement=all сделать только на Slave ?
вполне
LS
Чтобы на мастере диски не забились
LS
вполне
Спасибооо! Пойду херачить прод слейв))))