Postgres - проблемы с производительностью при запуске триггера на существующих данных - PullRequest
Новая
       32

Postgres - проблемы с производительностью при запуске триггера на существующих данных

0 голосов
/ 08 сентября 2018

У меня есть процесс, который обычно работает примерно так:

  1. Процесс Powershell вставляет записи в TABLE_A
  2. Триггер, определенный как «ПОСЛЕ ВСТАВКИ НА TABLE_A ДЛЯ КАЖДОЙ СТРОКИ .....», читает каждую строку, анализирует ее и затем загружает проанализированные данные в TABLE_B.

Это работало отлично в течение многих месяцев, каждый день вставлялось около 10 миллионов новых строк. Поскольку таблицы становятся достаточно большими, они разделены по дням и названы соответствующим образом. TABLE_A_20180807 и TABLE_B_20180807 и т. Д. И т. Д. *

Из-за недосмотра мне удалось создать недельные разделы TABLE_A без соответствующего триггера, поэтому в TABLE_B нет соответствующих записей.

Для повторной обработки существующих данных я применил следующий подход:

  1. Отключил каждый из разделов TABLE_A.
  2. Переименован каждый из отсоединенных разделов TABLE_A.
  3. Воссоздал правильные TABLE_A разделы с триггером на месте.

  4. Скопировал исходные данные из отдельной версии TABLE_A в правильную версию с помощью триггера, используя следующий запрос .... 

    INSERT INTO TABLE_A (field1, field2) 
SELECT field1, field2 FROM TABLE_A_20180807_BCK;

Это должно сработать, но пока (12 часов) он не дал никаких результатов.

У меня есть два вопроса:

  1. Это лучший способ запуска триггера для существующих данных?
  2. Можно ли как-то контролировать процесс и проверять, действительно ли он работает?

Я работаю с Postgres 10 на Windows. Все остальные сеансы были отключены заранее, я выполнил несколько случайных запросов, которые, как утверждают, выявляют проблемы с блокировками, но, похоже, они не указывают на отсутствие взаимоблокировок. Для запросов нажмите здесь . Я проверил TABLE_B, и нет никаких признаков того, что он становится больше, но я предполагаю, что новые строки не будут видны, пока не завершится вся транзакция?

Обновления в ответ на комментарии: Я почти уверен, что скорость триггера не является проблемой, при нормальных обстоятельствах записи загружаются со скоростью 1 запись в мс или 1000 в секунду. Это должно равняться 1 миллиону записей каждые 15 минут, поэтому моя таблица с 10 миллионами строк должна быть перезагружена примерно через 3 часа.

Хорошо - процесс наконец-то закончился, так что, я думаю, он не завис. Передача работала со скоростью около 100 записей в секунду или 10 мс на запись. Наверное, теперь возникает вопрос: почему каждая запись переносилась из другой таблицы в 10 раз дольше, чем при загрузке из внешнего источника?

...