Общие подходы такие (в порядке частоты использования): . Забить. . Обновлять в одном порядке. . Блокировать больше.

1. Не 2,3. Ну, придётся видимо потестить что быстрее.

1. Не 2,3. Ну, придётся видимо потестить что быстрее.

> 1. Не Почему бы нет? У Вас уже от этого есть проблемы с производительностью, прямо 100%?

> 1. Не Почему бы нет? У Вас уже от этого есть проблемы с производительностью, прямо 100%?

Нет, проблемы с эксепшенами от дедлоков.

@arxxxangel будет жить. Поприветствуем!

Нет, проблемы с эксепшенами от дедлоков.

Эээ... что? Какие от них могут проблемы? Ну повторите транзакцию N раз, и всё. Просто на всякий случай (если Вы вдруг не знаете): DEADLOCK — нормальная ситуация, "кинуть" его в любой момент может любая СУБД (когда ей "захочется"), и приложения обязаны их обрабатывать. Т.е., если корректность работы приложения нарушается от присутствия DEADLOCKs — в нём допущена (грубая) ошибка работы с транзакциями.

Эээ... что? Какие от них могут проблемы? Ну повторите транзакцию N раз, и всё. Просто на всякий случай (если Вы вдруг не знаете): DEADLOCK — нормальная ситуация, "кинуть" его в любой момент может любая СУБД (когда ей "захочется"), и приложения обязаны их обрабатывать. Т.е., если корректность работы приложения нарушается от присутствия DEADLOCKs — в нём допущена (грубая) ошибка работы с транзакциями.

Просвятите, что нормального в том, что две транзакции образуют дедлок? И как с этим быть в приложении?

Просвятите, что нормального в том, что две транзакции образуют дедлок? И как с этим быть в приложении?

Нормального в этом то, что они (и другие их аналоги, implicit rollbacks) теоретически неизбежны, и потому входят в любой протокол обеспечения изоляции транзакций. А как с этим быть в приложении, я уже написал выше.

ну, вот и буду либо сортировать видимо.

Просвятите, что нормального в том, что две транзакции образуют дедлок? И как с этим быть в приложении?

было время читал книгу по пхп мускулу и там прям конкретно описывалась эта ситуация... как всё запоминать ? ?

ну, вот и буду либо сортировать видимо.

Причём тут "сортировать"? Deadlock handling (т.е. повторы транзакций) обязан быть в приложении. А сортировать / блокировать — это deadlock avoidance (необязателен).

Причём тут "сортировать"? Deadlock handling (т.е. повторы транзакций) обязан быть в приложении. А сортировать / блокировать — это deadlock avoidance (необязателен).

сортировать это proactive problem solving ?

сортировать это proactive problem solving ?

Не solving, а avoidance. Т.е. избегание. В любой нетривиальной схеме и нагрузке Вы от них никуда не денетесь. Поэтому, пока не мешают... какая разница? Впрочем, если "сортировка" применяется заранее и ничего не стоит, это ещё лучше, естественно. ;)

Не solving, а avoidance. Т.е. избегание. В любой нетривиальной схеме и нагрузке Вы от них никуда не денетесь. Поэтому, пока не мешают... какая разница? Впрочем, если "сортировка" применяется заранее и ничего не стоит, это ещё лучше, естественно. ;)

Ваш посыл понятен. Но мне кажется недопустить проблеммной ситуации в моём случае дешевле чем разбираться с последствиями. Что я потом буду делать с этими транзакциями? Отдельную обработку писать для дедлокнувшихся? Сомнительно.

Ваш посыл понятен. Но мне кажется недопустить проблеммной ситуации в моём случае дешевле чем разбираться с последствиями. Что я потом буду делать с этими транзакциями? Отдельную обработку писать для дедлокнувшихся? Сомнительно.

> Но мне кажется недопустить проблеммной ситуации в моём случае дешевле чем разбираться с последствиями. Если у Вас случай тривиальный, Вам это удастся. А если нет — так нет. > Что я потом буду делать с этими транзакциями? Отдельную обработку писать для дедлокнувшихся? Сомнительно. Вы не поняли эту часть моего посыла, похоже. Такая обработка обязана быть, для всех транзакций в Ваших приложениях (если Вам важен результат, конечно). Если её нет, и Ваше приложение от этого ведёт себя как-то не так — это Ваша и только Ваша ошибка, без вариантов.

Sergey N будет жить. Поприветствуем!

Всем привет! Есть postgres. Настроена асинхронная репликация. Есть партицированная по дате таблица. Делаю запрос к ридонли реплике, и получаю ошибку что данные уже кто-то изменил на мастере, хотя изменений в старых таблицах нет. Куда смотреть?

Всем привет! Есть postgres. Настроена асинхронная репликация. Есть партицированная по дате таблица. Делаю запрос к ридонли реплике, и получаю ошибку что данные уже кто-то изменил на мастере, хотя изменений в старых таблицах нет. Куда смотреть?

Запрос может конфликтовать с вакуумом на мастере. Посмотрите про hot_standby_feedback.

Запрос может конфликтовать с вакуумом на мастере. Посмотрите про hot_standby_feedback.

Но данные в старых партициях не удаляются/изменяются

@winged_pegasus будет жить. Поприветствуем!

@BonartLeo будет жить. Поприветствуем!

@abespalov будет жить. Поприветствуем!

Друзья, Столкнулись с проблемой - постгря, обкурившись, использует hash join для двух больших таблиц Подсказками не решается - EF Core не умеет их генерировать в своих запросах. Что можно сделать? Индексы все есть, при недельных выборках план запроса использует нормальные Nested Loops для больших таблиц и хеш для маленьких. Но месячная выборка почему-то генерит план с полным чтением большой таблицы и hash join.

Чем тут можно помочь? Вес рандомного чтения страниц понижали, памяти для кеша добавляли - результат тот же

Сохраняю clob в postgresql а в базе вижу 7 значное число. Что за фигня?

@yourmommy1488 будет жить. Поприветствуем!

Но данные в старых партициях не удаляются/изменяются

Интересно. А подробнее (какая версия PostgreSQL, какой вид партционирования, какие настройки)?

@steelden будет жить. Поприветствуем!

Друзья, Столкнулись с проблемой - постгря, обкурившись, использует hash join для двух больших таблиц Подсказками не решается - EF Core не умеет их генерировать в своих запросах. Что можно сделать? Индексы все есть, при недельных выборках план запроса использует нормальные Nested Loops для больших таблиц и хеш для маленьких. Но месячная выборка почему-то генерит план с полным чтением большой таблицы и hash join.

> Столкнулись с проблемой - постгря, обкурившись, использует hash join для двух больших таблиц А может, правильно делает? Или Вы cost-ы неправильно выставили? Можете EXPLAIN (ANALYZE, BUFFERS) показать (если это не слишком долго)?

Делает неправильно - недельная выборка 10 секунд, месячная - 216, гребет в процессе целиком (seq scan) таблицу с 600 тысячами записей.

Делает неправильно - недельная выборка 10 секунд, месячная - 216, гребет в процессе целиком (seq scan) таблицу с 600 тысячами записей.

Почему "неправильно"-то. Вы сравнивали? Убедились, что cost-ы у Вас правильно указаны, что estimated rows близки к реальности?

Интересно. А подробнее (какая версия PostgreSQL, какой вид партционирования, какие настройки)?

10.3, партицирована по ranges на поле с датой

> Но мне кажется недопустить проблеммной ситуации в моём случае дешевле чем разбираться с последствиями. Если у Вас случай тривиальный, Вам это удастся. А если нет — так нет. > Что я потом буду делать с этими транзакциями? Отдельную обработку писать для дедлокнувшихся? Сомнительно. Вы не поняли эту часть моего посыла, похоже. Такая обработка обязана быть, для всех транзакций в Ваших приложениях (если Вам важен результат, конечно). Если её нет, и Ваше приложение от этого ведёт себя как-то не так — это Ваша и только Ваша ошибка, без вариантов.

2. Согласен, согласен. 1. Но, т.к. в моём тривиальнейшем случае это действительно дешевле, п.2 отменяется = )

10.3, партицирована по ranges на поле с датой

А план запроса показывает обращение только к старым данным, т.е. partition pruning случается, и "новых" partitions в плане запроса уже нет?

Делает неправильно - недельная выборка 10 секунд, месячная - 216, гребет в процессе целиком (seq scan) таблицу с 600 тысячами записей.

И всё же, лучше всего будет показать EXPLAIN, IMHO.

И всё же, лучше всего будет показать EXPLAIN, IMHO.

Разумеется

А план запроса показывает обращение только к старым данным, т.е. partition pruning случается, и "новых" partitions в плане запроса уже нет?

Да, только нужные, но это в explain без analyze

Да, только нужные, но это в explain без analyze

Так это и хорошо, казалось бы... А ошибка какая, можете показать полностью?

Так, пока отбой - вижу нереально тормозящую выборку из самой тяжелой таблицы еще до join

Так это и хорошо, казалось бы... А ошибка какая, можете показать полностью?

Уже завтра точно скажу

а кто в курсе что делать если не получается внести в таблицу текст с символом типа ® ?

в мускуле это решалось сменой коллейшна и типа соединения

а кто в курсе что делать если не получается внести в таблицу текст с символом типа ® ?

то есть с любым символом трабл?

а что если там емодзи?

то есть с любым символом трабл?

только со всякими специфическими

эмодзи тож не считывает

какой коллейшн?))

какой коллейшн?))

это ютф?

это ютф?

да, по идее

®

этот значок

ProgrammingError: (psycopg2.ProgrammingError) syntax error at or near "s®" LINE 1: ...on, price, picture, vendor) VALUES ('Ботинки Levi's®', 'men'...

ProgrammingError: (psycopg2.ProgrammingError) syntax error at or near "s®" LINE 1: ...on, price, picture, vendor) VALUES ('Ботинки Levi's®', 'men'...

жесть но он пишет что дело в синтаксисе ?

это slqalchemy

ProgrammingError: (psycopg2.ProgrammingError) syntax error at or near "s®" LINE 1: ...on, price, picture, vendor) VALUES ('Ботинки Levi's®', 'men'...

может не правильно читает строку

экранировать попробуй

экранировать попробуй

это не надо экранировать)

там только всякие спец-символы типа кавычек

это не надо экранировать)

Да я хозе обычно если какой то трабл со строками то экранирую

там только всякие спец-символы типа кавычек

'Ботинки Levi's®' Сколько здесь одинарных кавычек?

'Ботинки Levi's®' Сколько здесь одинарных кавычек?

бляяяяя

точно

сори

???

я тупанул

)))

не в ту сторону подумал

вот и я о чем

думаю что не так

да я не понял просто даже))

спасибо!

вы там напрямую строки конкатенируете?

http://initd.org/psycopg/articles/2012/10/01/prepared-statements-psycopg/

есть еще вроде parametrized statements, скорее всего дял одноразовых запросов еще лучше подойдет

есть еще вроде parametrized statements, скорее всего дял одноразовых запросов еще лучше подойдет

да думаю экранировать быстрее будет

вы потом бобби тейблса словите

есть еще вроде parametrized statements, скорее всего дял одноразовых запросов еще лучше подойдет

что ита

насколько понимаю, то же самое, только не prepared

но я не питонист и вообще просто прогуглил

Кстате нормально ли использовать часто тип String (из sequelize) для маленьких строк до 30 символов?

но я не питонист и вообще просто прогуглил

а я нодер и не понимаю

насколько понимаю, то же самое, только не prepared

ну в php pdo вроде такое есть