Проблема - резко возрастает время выполнение функии при многократном ее выполнении

pif
Дата: 14.10.2003 13:32:29
Суть вопроса: существует фактическая необходимость несколько раз в день выполнять функцию (plpgsql), которая полностью удаляет данные из таблицы, затем вставляет и апдейтид вставленные записи. Количество записей в таблице для вставки/удаления - около 35тыс. Количество для апдейта - около 28тыс записей. Зачем это все надо при необходимости могу рассказать, но поверь, что необходимость обоснована. Удаление происходит командой delete, т.к. TRUNCATE не работает в функциях. Собственно проблемма - с каждым новым запуском время выполнения функции увеличивается на 30-50%!! Выполнение команды vacuum или vacuum analyze между запусками функции только лишь замедляет рост. Безусловно, помогает удаление таблицы и создание ее снова, но это я рассматриваю как крайнее средство.
И еще: эксперементировал я сначала на Postgres 7.3.1 for Windows (WinXP Pro) с временем выполнения функции - 1'10''; 1'42'';3'05'' и т.д. вплоть до 10 минут. Решил, наверно, Postgres не любит Билла. На том же железе живет у меня Linux ASP 7.3 + Postgres 7.3.3. Эксперимент привел меня к выводу, что надо просить помощи - 3'53; 4'31; 5'47; 9'22 - я сдался.
Сам я пришел в Постгрес из MsSQL, может у меня просто не тот подход. Может неправильно согласно канонам Постгреса "зашивать" бизнес-логику в функции, а надо возлагать это на плечи клиента?
Sad Spirit
Дата: 14.10.2003 21:58:16
Поверю на слово, что такая последовательность действий необходима. ;)
Судя по симптомам (отсутствию пользы от vacuum) у тебя индекс(ы) распухают. Попробуй следующее:
  • удали все индексы по таблице (для последующих запросов seq scan всё равно быстрее)
  • удали/вставь/обнови записи
  • vacuum analyze
  • создай индексы
  • Shweik
    Дата: 14.10.2003 22:48:28
    Радикальное воздействие на реальный размер базы оказывает
    комманда VACUUM FULL.
    А для очистки индексов от мусорных веток знатоки рекомендовали:
    > REINDEX -- rebuild corrupted indexes
    >Synopsis
    >REINDEX { TABLE | DATABASE | INDEX } name [ FORCE ]
    Я думаю в комплексе эти комманды могут решить многое.
    VACUUM ANALYZE (сорри за воольный пересказ) - Обновляет статистику используемую планировщиком для определение наиболее эффективного
    пути выполнения запроса.
    >Updates statistics used by the optimizer to determine the most efficient way to >execute a query.
    На размер базы ключ ANALYZE не влияет.
    Те можно предположить блоки убитые delete остаются в базе и дефрагментируют ее. Знакомый с таким сталкивался при работе со статистикой каналов. -
    при свертывани дневных отчетов где количество записей около 1.5*10^6
    в квартальный размер базы тормоза наступали оччень быстро.
    Если кто уверен в обратном - поведайте Вашу точку зрения.