1.Есть ряд обучающих материалов по изоляции транзакций за авторством Е.Рогова, например, https://habr.com/ru/company/postgrespro/blog/442804/. 2.В этих материалах автор предостерегает от ошибок связанных, с тем что в одном запросе идет проверка, а в другом запросе по результатам проверки, осуществляются действия с этой записью. Автор считает такой подход антипаттерном, т.к. между двумя этими запросами в параллельном потоке эта запись может быть изменена.
В статье сказано, что "Файлы журнализации нужны для того, чтобы обеспечить работоспособность реляционных баз данных в терминах ACID. Напомню, что ACID — это набор свойств реляционной базы данных, которые гарантируют в том числе надёжность транзакции". В соответствии с документацией файлы журнала прежде всего существуют для безопасного восстановления после краха сервера.
Правильно, ли я понимаю, что количество версий строк зависит, от интенсивности обновления строки и настроек автовакуума? И если это так, то при одной версии строки (вставили строку и после не было обновлений и удаления этой строки) речь о корреляции вообще не должна идти, потому что не с чем коррелировать, т.е. нет версий строк?
"Ситуация с доступом к таблице меняется, когда корреляция оказывается низкой. Создадим индекс по столбцу book_date, имеющему практически нулевую корреляцию с индексом, и посмотрим на запрос, выбирающий приблизительно ту же долю строк, что и в предыдущем примере. Индексный доступ оказывается настолько дорогим (56957 против 4639 в хорошем случае), что планировщик выбирает его, только если запретить ему все альтернативы"
Не совсем ясно, почему такая высокая стоимость. Правильно ли я понимаю, что такая ситуация может возникнуть, если для одной строки имеется достаточно большое количество версий строк, разбросанных по разным страницам и процедура очистки не выполнялась. Если выполнить очистку, то стоимость снизится до "хорошего случая".
Вы очень хороша написали, как рассчитывается стоимость каждого метода доступа, и в общих чертах далее пояснения в каких случаях используется тот или иной метод доступа. Вопрос - есть ли какие-то критерии на основе которых выбирается метод доступа? Может быть есть какие-то ориентировочные значения данных критериев? Данные знания могут помочь при оптимизации запросов.
Так и ADD COLUMN создаст такие же проблемы. Тогда в чем преимущество добавление колонки по сравнению с её переименованием, если и там и там требуется ACCESS EXCLUSIVE, только после переименования таблица готова для работы с новой колонкой, а после добавления требуются дополнительные манипуляции по переносу данных?
Прочитал статью и так же сразу не понял, что речь идет о двух конкурирующих транзакций. Статья начинается с того, что ловится deadlock на операции UPDATE и сразу возникает вопрос, а как это может быть. Начинаешь читать дальше и предлагается взглянуть под другим углом. Но не слово о том, что этот дидлок изначально был вызван двумя транзакциями.
Если после исключения ноды из кластера вернуть её обратно командой docker service scale $patroni2-id=1, то наблюдается следующий эффект:
— команда patronictl -c /etc/patroni.yml list patroni показывает что она в кластере, но по факту в репликацию эта нода не встала, в логах постгреса наблюдается ошибка репликации. Это лечится путем удаление содержимого каталога кластера. После этого этот каталог восстанавливается с мастера и репликация налаживается.
— сервис haproxy, даже после восстановлении нормальной репликации, не может соединится с этой нодой и соответственно при очередном файрволе, даже если патрони переключится на новый мастер, доступа через haproxy к базе не будет. Как это лечится не понятно.
Вывод: пока не совсем надежна эта конфигурация в среде docker swarm.
Чтобы лучше понимать какой объем данных обрабатывается при выполнении запросов необходимо использовать в EXLAIN опцию BUFFERS. Вы её почему-то не используете.
При апдейте строки, если это возможно, Постгрес поставит новую копию строки сразу после старой копии строки. Плюс в старой копии строки проставляется специальная метка, для того чтобы Постгрес знал, что новая копия строки находится сразу после старой. Поэтому обновлять все индексы не нужно.
Что будет, если в процессе автовакуума будет удалена старая версия строки?
Насколько быстрее в итоге прошла миграция базы данных? Вы так и не сказали.
Интересно, как сочетается pgbouncer и подготовленные запросы?
+1
1.Есть ряд обучающих материалов по изоляции транзакций за авторством Е.Рогова, например, https://habr.com/ru/company/postgrespro/blog/442804/.
2.В этих материалах автор предостерегает от ошибок связанных, с тем что в одном запросе идет проверка, а в другом запросе по результатам проверки, осуществляются действия с этой записью. Автор считает такой подход антипаттерном, т.к. между двумя этими запросами в параллельном потоке эта запись может быть изменена.
В статье сказано, что
"Файлы журнализации нужны для того, чтобы обеспечить работоспособность реляционных баз данных в терминах ACID. Напомню, что ACID — это набор свойств реляционной базы данных, которые гарантируют в том числе надёжность транзакции".
В соответствии с документацией файлы журнала прежде всего существуют для безопасного восстановления после краха сервера.
Дополнительно, раз уж пошла речь про особенности работы с NULL, то есть видео
https://www.youtube.com/watch?v=2qTczke77q4
Правильно, ли я понимаю, что количество версий строк зависит, от интенсивности обновления строки и настроек автовакуума? И если это так, то при одной версии строки (вставили строку и после не было обновлений и удаления этой строки) речь о корреляции вообще не должна идти, потому что не с чем коррелировать, т.е. нет версий строк?
А что понимается под термином "версия табличной строки"? Это связано с MVCC?
"Ситуация с доступом к таблице меняется, когда корреляция оказывается низкой. Создадим индекс по столбцу
book_date, имеющему практически нулевую корреляцию с индексом, и посмотрим на запрос, выбирающий приблизительно ту же долю строк, что и в предыдущем примере. Индексный доступ оказывается настолько дорогим (56957 против 4639 в хорошем случае), что планировщик выбирает его, только если запретить ему все альтернативы"Не совсем ясно, почему такая высокая стоимость. Правильно ли я понимаю, что такая ситуация может возникнуть, если для одной строки имеется достаточно большое количество версий строк, разбросанных по разным страницам и процедура очистки не выполнялась. Если выполнить очистку, то стоимость снизится до "хорошего случая".
Вы очень хороша написали, как рассчитывается стоимость каждого метода доступа, и в общих чертах далее пояснения в каких случаях используется тот или иной метод доступа. Вопрос - есть ли какие-то критерии на основе которых выбирается метод доступа? Может быть есть какие-то ориентировочные значения данных критериев? Данные знания могут помочь при оптимизации запросов.
Вы сказали, что
Какова практическая ценность подготавливать запросы, кроме как защита от sql - инъекций?
Так и ADD COLUMN создаст такие же проблемы. Тогда в чем преимущество добавление колонки по сравнению с её переименованием, если и там и там требуется ACCESS EXCLUSIVE, только после переименования таблица готова для работы с новой колонкой, а после добавления требуются дополнительные манипуляции по переносу данных?
Rename тоже требует ACCESS EXCLUSIVE. И почему эта операция, как и ADD в большинстве случаев может быть не незаметной?
Прочитал статью и так же сразу не понял, что речь идет о двух конкурирующих транзакций. Статья начинается с того, что ловится deadlock на операции UPDATE и сразу возникает вопрос, а как это может быть. Начинаешь читать дальше и предлагается взглянуть под другим углом. Но не слово о том, что этот дидлок изначально был вызван двумя транзакциями.
— команда patronictl -c /etc/patroni.yml list patroni показывает что она в кластере, но по факту в репликацию эта нода не встала, в логах постгреса наблюдается ошибка репликации. Это лечится путем удаление содержимого каталога кластера. После этого этот каталог восстанавливается с мастера и репликация налаживается.
— сервис haproxy, даже после восстановлении нормальной репликации, не может соединится с этой нодой и соответственно при очередном файрволе, даже если патрони переключится на новый мастер, доступа через haproxy к базе не будет. Как это лечится не понятно.
Вывод: пока не совсем надежна эта конфигурация в среде docker swarm.
Можете поделиться опытом, почему вы не рекомендуете использовать pgpool
Что будет, если в процессе автовакуума будет удалена старая версия строки?