COPY?

https://www.postgresql.org/docs/9.6/static/populate.html

Ага, спасибо большое

Как все сложно If you are adding large amounts of data to an existing table, it might be a win to drop the indexes, load the table, and then recreate the indexes.

для скорости. автовакуум ещё выключить можно

COPY?

Если я правильно понимаю, то ему на вход нужно давать красивый файл в формате CSV/TSV, да?

Именно, но это можно делать в конвейере

Если я правильно понимаю, то ему на вход нужно давать красивый файл в формате CSV/TSV, да?

ага, перегенерить файлы питончиком/шеллом в CSV и понятный для COPY формат

Привет всем Стоит задача запихнуть данные из текстовых файлов в таблицу постгресса. Делаю это пайтон скриптом через SQLAlchemy, делаю commit каждые 10000 add'ов Как можно ускорить это дело? Выходит гдето миллион записей в час, хочется быстрее

Я 30913732 записей за 39минут загружаю

ты прост, алхимию не правильно готовишь

т.е средний RPS на вставку во временную таблицу без индексов и FK равен 13179

действительно, удалите индексы и внешние ключи, урежьте wal, зафиксируйте план через prepare и посмотрите, что покажет обычный insert из алзимии. и только если не пойдет, парсите csv

ты прост, алхимию не правильно готовишь

Вопрос как раз был в том, как ее правильно использовать. Если RPS ~13к то наверное комиты можно раз в 1кк записей делать?

Вопрос как раз был в том, как ее правильно использовать. Если RPS ~13к то наверное комиты можно раз в 1кк записей делать?

Го в личку

надо в конце, после END поставить точку с запятой: END;

неа, не работает

после insert точка с запятой стоит?

да, после окончания списка values тоже должно быть ;

do $$ begin for i in 1..10 loop perform i; end loop; end $$;

а вообще, loop - это антипаттерн, не делайте так.

мне просто нужно создать 20 записей, для теста

чтобы не заполнять 100500 раз

generate_series вам поможет

хм, посмотрю

а вообще, loop - это антипаттерн, не делайте так.

А что не так с loop?

производительность по сравнению с обычным запросом на generate_series, например

Ясно понятно, спасибо )

да с gen_series проще, а помимо цифр и дат можно так же пройтись по символам?

типа от A до Z

легко, например: SELECT chr (64 + i) FROM generate_series (1, 26) AS i

спасибо =)

привет чяднт?) user@host ~/sql/et $ psql -U etUser -d etProd psql (9.6.1) Type "help" for help. user@host ~/sql/et $ pg_basebackup -D ./bbkup -U etUser -d etProd pg_basebackup: missing "=" after "etProd" in connection info string

в pg_hba стоит локальный trust

Добавь -h localhost

И pg_basebackup не под простым юзером работает

добавил хост и порт, попробоват от -d postgres, попробовал с sudo

привет чяднт?) user@host ~/sql/et $ psql -U etUser -d etProd psql (9.6.1) Type "help" for help. user@host ~/sql/et $ pg_basebackup -D ./bbkup -U etUser -d etProd pg_basebackup: missing "=" after "etProd" in connection info string

https://postgrespro.ru/docs/postgrespro/9.6/libpq-connect.html#libpq-connstring

bingo

спасибо

Когда вы используете -d строка подключения должна выглядеть так, как нарисовано в документе по ссылке, в вашем случае -d "dbname=etProd"

И вообще оно вам не нужно, там весь кластер бекапится

да, я ман по диагонали читал, мол "-d" - а ну это как в psql наверное

база маленькая

сейчас она pg_dump бекапится

И pg_basebackup не под простым юзером работает

юзер - пофиг, главное, чтобы этот user мог писать туда, куда собирается.

А вообще, попробуйте barman

юзер - пофиг, главное, чтобы этот user мог писать туда, куда собирается.

Имею ввиду юзер в бд. postgres обычно

А вообще, попробуйте barman

спасибо, думаю о бармане или pgprobackup

Игорь тогда надо не просто говорить, а указывать, что у юзера, которым подключаешься, должно быть право replication, ну или суперпользователем.

спасибо, думаю о бармане или pgprobackup

pg_probackup - это правильное пиво. :)

pgprobackup классный, он может контрольные суммы читать и проверять, что таблицы реально живые. и может инкрементальный бекап на файловом уровне объектов бд...правда все эти вкусности, вроде только для сборки postgres pro. но у них есть standart, он бесплатный

pg_probackup - это правильное пиво. :)

Пользуюсь барманом , + скидываю в Амазон

зато барман может из одного места бекапить кучу разных серверов, а пробекап - он на сервере базы

pgprofessionals на pgConf сказали, что pg_probackup работает с ванильным постгресом за исключением ptrack

Причем у бармана есть дедупликация , архиывы меньше места занимают

А вот у pgbackrest есть все кроме pg_recievexlog и как мне тут указали не все checksum

еще есть форк бармана

от яндекса

ссылкаесть ?

его тестил не давно, вроде ниче

pgprofessionals на pgConf сказали, что pg_probackup работает с ванильным постгресом за исключением ptrack

без ptrack не так интересно

https://github.com/secwall/barman

там фича - инкр бэкап и на логи и на сам бэкап

Барман могЁтЪ диффы файлов делать, как это делает пробекап? Т.е. в случае инкрементального бекапа у пробекапа сохраняются только измененные страницы соответствующих файлов.

ERROR: S client not available

Барман могЁтЪ диффы файлов делать, как это делает пробекап? Т.е. в случае инкрементального бекапа у пробекапа сохраняются только измененные страницы соответствующих файлов.

оригинальный - точно нет. а вот яндексовский форк - надо смотреть

Может брать только измененные страницы (ориентируется на LSN в page-header’е, PostgreSQL 9.3+)

https://pgday.ru/files/papers/80/pgday2016_backups.pdf

еще мне приглянулось вот это https://github.com/ossc-db/pg_rman

Incremental backup Backup only files or pages modified after the last verified backup with the same timeline.

я слышал на pgconf от разработчиков, что они "вдохнавлялись" pg_rman, когда pg_probackup писали

а разве не pg_arman?

он мне вообще не понравился

а разве не pg_arman?

я подслушивал за обедом, мог и не так услышать)

я нашел на гитхабе

Original fork of pg_probackup can be found at https://github.com/michaelpq/pg_arman.

точно арман

Original fork of pg_probackup can be found at https://github.com/michaelpq/pg_arman.

?

Добрый день! Кто какие методы аутентификации использует в pgbouncer? в частности интересует какой максимально защищенный способ подключения и проверки пользователей можно сделать используя pgbouncer?

pgbouncer 1.7 SSL

Вечера доброго! Есть ассинхронная репликация в продакшне, но возникла проблема с необходимостью синхронизации лишь в одном, не очень часто выполняемом, запросе. Если я переведу репликацию в синхронный режим, но установлю глобально synchronous_commit = off, и буду лишь для нужных трансакций выставлять его в on, может ли что-то в системе поменяться? Будет ли потеря в производительности?

если сомнения, что перевод в подобный "псевдо-синхронный" (как я его понимаю) режим как-то повлияет на работу системы, придётся искать иные пути решения проблемы, типа ручной проверки синхронизации на standby

* сомнения оправданы

Даже при самом ожидаемом(желаемом) поведении репликации есть шансы в момент синхронизации это запроса просесть очень сильно, поскольку асинхронная репликация может без труда накопить отставание в реплэе

Это даже закрыв глаза на большие выборки с реплики, которые могут вызвать еще большее отставание реплэя

Ага. То есть получается, что sync_commit=local (не off, конечно, был неправ) при включённой синхронной репликации может и будет себя вести как несинхронная, но синхронный коммит будет ожидать полной синхронизации, а не только своей личной? Не знаю, правильно ли понял, но звучит логично. Хорошо.. а те 100500 паралельно исполняемых трансакции, они-то тупить не будут?

И стоп, разве ro-выборки на standby могут задержать синхронизацию?

И стоп, разве ro-выборки на standby могут задержать синхронизацию?

Естественно. По диску.

А, ну по диску-то... Это надо обдумать. Я-то по наивности думал, что у чтение из стэндбая на репликацию влият минимально, иначе как-то страшно становится.. Специально все выборки ж на standby выводил

долгие выборки на standby могут привести к блокировке репликации

если одновременно будет автовакум передавать с мастера свои изменения

Спасибо, буду иметь в виду. А эти задержки отражаются в pg_last_xact_replay_timestamp()?

да, задержка будет отражатся

Ладно, оно ж, тьфу-тьфу-тьфу, годами нормально работало в несинхронном режиме. Проблема-то небольшая - иногда происходит insert, и много раз чтение, уже из standby - и иногда чтение не выдаёт только что добавленную запись, что логично; вопрос, что с этой по сути мелкой бедой делать, при этом ничего не сломав. Читать с мастера ну совсем не хочется...

Если вдруг ваш случай вырождается в единственное условие "клиент, добавивший запись, должен видеть ее во всех последующих запросах", то можно не отвечать клиенту успехом, пока записывающее приложение не прочитает запись с реплики или не словит таймаут.