Почему это так долго работает?

Делайте кусками по 1000 записей например, будет быстро

а почему так?

Для начала разговора о скорости запросов предоставьте информацыю из закрепа: https://t.me/pgsql/303899 Для этого можно воспользоваться вот этим скриптом: https://t.me/pgsql/476688 Без всей этой информацыи такой разговор будет беспредметным. PS И да, не надо постить текст картинками.

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

Показать explain analyze, всё равно, что дождать окончания запроса

analyse^w

Ну, можно немного подумать и сделать без analyze так или иначе.

Limit 10 поставьте и покажите

если по другому не можете, отмените, добавьте к запросу explain (analyze) *SQL* limit 10

Чем не нравится, минусующие?

По остальной информацыи — ужэ можно будет думать, ковырять блокировки или это 10ТБ табличка на HDD.

ты делить на куски вручную будешь?

Почему бы и да?

Тем, что это почти всегда только увеличит общее время выполнения, может быть? ;)

Я пишу для этого простенький запрос

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

Всем. Во-первых, обновление батчами работает ДОЛЬШЭ. Чуть менее, чем всегда. Один батч — да, можэт и быстрее. Всё вместе — почти всегда дольшэ, зачастую сильно. Во-вторых, нет никакого смысла рыпаться пока не определил, что там стряслось. Если это блокировка — то она точно такжэ будет висеть при батче. В-третьих — это не так просто. Определить нормальные батчи, которые обновят в итоге всё и не будут по 20 раз обновлять одно и тожэ. В-четвёртых — не всегда нетранзакцыонное обновление вообще допустимо.

Ого! То есть заблокировать на бою таблицу на пол суток это нормально? А батчами это моветон. Ну-ну

Если Вам действительно нужна помощь — покажите https://t.me/pgsql/498954 , только EXPLAIN со всеми теми параметрами, кроме ANALYZE.

Ну, во-первых только частично заблокировать. Во-вторых — бой бою рознь. Кое-где — да, никаких проблем вообще, каждую неделю есть тех.окно на 56 часов.

На больших таблицах в рабочей среде всегда быстрее. И сильно, просто потому, что не надо ждать exclusive lock

ЧТО. ВЫ. НЕСЁТЕ?!?

Опасно сказал!

А что Вы имеете в виду под "заблокировать на бою таблицу на пол суток"? Что, от этого чтения заблокируются, что ли? Или обновления пока не заблокированных записей?

в UPDATE нет exclusive lock

Ну, по сути — есть. На каждую обновлённую строчку.

Да, погорячился

Речь про изменения, конечно, которые будут ждать вашего апдейта

угу. но он возникает только в момент, когда появляется другой желающий потрогать эту строчку

Всё это, безусловно, так. Но мы же ещё не знаем, в чём там причина, вот в чём смысл. Зачем такие советы давать "вслепую", я не понимаю (может стать только хуже, как пишет https://t.me/pgsql/498969 ).

Не факт, что такие изменения там вообще есть. Т.е. https://t.me/pgsql/498983

Тон попроще. Я не несу, а делюсь опытом. Который нашел подтверждение совсем недавно, на табличке 2млн. записей, всего-то. Но зато интенсивно изменяемой.

Слушайте, вы в чятике инжэнеров. Тут любят спорить. Постарайтесь формулировать... Точнее, что ли. И обоснованнее.

Надо добавить «русскоязычных», это сильно меняет тон разговора почему-то.

На самом деле, если завис конкретный запрос — можно сразу глянуть/выложыть SELECT * FROM pg_stat_activity и SELECT * pg_locks — чтобы посмотреть, что он висит на блокировке или не висит.

Меньшэ, чем мне казалось 10 лет назад.

Mr. N

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

И потом — ну, по какой 1000 записей? Сейчас 1991 год что ли? Логичные батчи по-моему начинаются где-то от миллиона (на типичных данных и при типичных требованиях к доступности сервиса).