Производительность предложения SQL Postgres

Question

У меня экземпляр Postgres, работающий на рабочей станции 16-ядерный / 32 Гб WIndows Server.

Я следовал советам по повышению производительности, которые я видел в таких местах: https://www.postgresql.org/docs/9.3/static/performance-tips.html.

Когда я запускаю обновление, например:

analyze;
update amazon_v2 
  set states_id = amazon.states_id, 
  geom = amazon.geom
from amazon
where amazon_v2.fid = amazon.fid

, где fid - первичный ключ вОбе таблицы и обе имеют 68M записей, на их выполнение уходит почти день.

Есть ли способ повысить производительность SQL-предложений, подобных этой?Должен ли я написать хранимую процедуру для обработки записи запись за записью, например?

Answer 1

Ваш запрос выполняется в самой журнальной транзакции.Транзакция может быть заблокирована другими авторами.Запрос pg_locks .

Длинные транзакции негативно влияют на производительность автоочистки.Время выполнения увеличивается в другое время?Если так, проверьте таблица раздувается .

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

Вы также должны следовать советам https://stackoverflow.com/a/50708451/6702373

Подведем итог:

• Обновлять только измененные строки (если изменено только несколько строк))

• Проверка блокировок

• Проверка увеличения таблицы

• Проверка использования оборудования (связана с другими проблемами))

• Разделить операцию на пакеты.

• Заменить обновления на удаление / усечение и вставка / копирование (это работает, если обновление изменяет большинство строк).

• (если больше ничего не помогает) Таблица разделов

Answer 2

Вы не показываете план выполнения, но держу пари, что он, вероятно, выполняет полное сканирование таблицы на amazon_v2 и использует поиск индекса на amazon.

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

Другая совершенно другая стратегия - обновлять только «измененные» строки.Возможно, вы сможете отследить их, чтобы не обновлять все 68 миллионов строк каждый раз.