СК
если вписывается уже имеющее значение, то думаю должно распараллелиться.. но Алексей прав, лучше теста вам это ничего не покажет )
Size: a a a
2021 March 26
RD
если вписывается уже имеющее значение, то думаю должно распараллелиться.. но Алексей прав, лучше теста вам это ничего не покажет )
ок, буду тогда наблюдать дальше, спасибо)
AL
Всем привет, знатоки подскажите пожл, к примеру ситуация такая: запущены 3 потока(пусть это будут горутины на go), которые выполняют вставку(30к строк за раз) данных в одну таблицу, так вот, вставка будет параллельная или последовательная? То есть к примеру все потоки одновременно отправили данные на вставку(одна порция 30к строк ~ 10секунд ), в итоге общее время вставки с точки зрения pg, будет ~30 сек или ~10 сек?
> в итоге общее время вставки с точки зрения pg, будет ~30 сек или ~10 сек?
10 сек. это если нет обстоятельств которые могут задержать запись (например блокировки или общая перегрузка)
не вдаваясь в детали, запись в постгресе буферизованная, все вставки будут сделаны в буферах постгреса (которые в RAM), потом придет фоновый процесс и сбросит все данные на диск - все это прозрачно для клиента. Запись в WAL журнал будет сериализована.
10 сек. это если нет обстоятельств которые могут задержать запись (например блокировки или общая перегрузка)
не вдаваясь в детали, запись в постгресе буферизованная, все вставки будут сделаны в буферах постгреса (которые в RAM), потом придет фоновый процесс и сбросит все данные на диск - все это прозрачно для клиента. Запись в WAL журнал будет сериализована.
AL
можете почитать эту главу, тут описано как устроено чтение и запись в постгресе
P
@lesovsky все, вроде, отпустило. После рестарта и pgsql и мамонсу
AL
RD
> в итоге общее время вставки с точки зрения pg, будет ~30 сек или ~10 сек?
10 сек. это если нет обстоятельств которые могут задержать запись (например блокировки или общая перегрузка)
не вдаваясь в детали, запись в постгресе буферизованная, все вставки будут сделаны в буферах постгреса (которые в RAM), потом придет фоновый процесс и сбросит все данные на диск - все это прозрачно для клиента. Запись в WAL журнал будет сериализована.
10 сек. это если нет обстоятельств которые могут задержать запись (например блокировки или общая перегрузка)
не вдаваясь в детали, запись в постгресе буферизованная, все вставки будут сделаны в буферах постгреса (которые в RAM), потом придет фоновый процесс и сбросит все данные на диск - все это прозрачно для клиента. Запись в WAL журнал будет сериализована.
большое спасибо за ответ
RD
можете почитать эту главу, тут описано как устроено чтение и запись в постгресе
ок иду читать
b
ограничение по pk:
id int8 NOT NULL GENERATED ALWAYS AS IDENTITY,
id int8 NOT NULL GENERATED ALWAYS AS IDENTITY,
В этом случае переданное вами значение проигнорируют, если пару слов волшебных не скажете.
RD
В этом случае переданное вами значение проигнорируют, если пару слов волшебных не скажете.
да, эт я учел) OVERRIDING SYSTEM VALUE
KG
Коллеги добрый день имеется кластер patroni
ZE
Всем привет кто может подсказать я хочу что-бы если od.with_payment равен не null выводить ac.payment_type иначе что-бы выводился Null
Правильный ли это запрос для этой задачи? Просто я не увидел не одного null и закрались сомнения а будет ли он вообще выводить Null?
Правильный ли это запрос для этой задачи? Просто я не увидел не одного null и закрались сомнения а будет ли он вообще выводить Null?
select ac.payment_type from acceptance_check as ac left join order_detail od on ac.contract_number = od.contract_number order by (case when od.with_payment is not null then ac.payment_type else null END)
KG
К нему подключается standby реплика. При этом standby master успешно запускается. А вот standby реплика нет. При этом если вручную запустить pg_basebackup он висист на сообщениии начинается базовое резервное копирование, ожидается завершение контрольной точки
AL
К нему подключается standby реплика. При этом standby master успешно запускается. А вот standby реплика нет. При этом если вручную запустить pg_basebackup он висист на сообщениии начинается базовое резервное копирование, ожидается завершение контрольной точки
как-то сумубрно получилось, в чем у вас проблема-то?
> pg_basebackup он висист ... ожидается завершение контрольной точки
пропишите
> pg_basebackup он висист ... ожидается завершение контрольной точки
пропишите
checkpoint: 'fast' в настройках патрони (см. документацию)KG
как-то сумубрно получилось, в чем у вас проблема-то?
> pg_basebackup он висист ... ожидается завершение контрольной точки
пропишите
> pg_basebackup он висист ... ожидается завершение контрольной точки
пропишите
checkpoint: 'fast' в настройках патрони (см. документацию)kb-scim1 | 10.236.69.83 | Replica | creating replica | | unknown |
| kb-scim2 | 10.236.69.84 | Standby Leader | running | 13 | |
| kb-scim2 | 10.236.69.84 | Standby Leader | running | 13 | |
AL
смотрите логи патрони на предмет ошибок
KG
Вот такое состояние standby
KG
в том и дело что ошибок нет
AL
ну вот статус creating replica - значит реплика в процессе создания... какой у вас размер БД?
AL
или подключитесь через psql в БД (на мастере) и выполните команду
checkpoint;