Тъй като обединявате две големи таблици и няма условия, които биха могли да филтрират редове, единствената ефективна стратегия за присъединяване ще бъде хеш присъединяване и никакъв индекс не може да помогне с това.
Първо ще има последователно сканиране на една от таблиците, от която се изгражда хеш структура, след това ще има последователно сканиране на другата таблица и хешът ще бъде изследван за всеки намерен ред. Как някой индекс може да помогне с това?
Може да очаквате такава операция да отнеме много време, но има някои начини, по които можете да ускорите операцията:
-
Премахнете всички индекси и ограничения на
tx_input1преди да започнеш. Вашето запитване е един от примерите, при които индексът изобщо не помага, а всъщност вреди производителност, тъй като индексите трябва да се актуализират заедно с таблицата. Създайте отново индексите и ограниченията, след като приключите сUPDATE. В зависимост от броя на индексите в таблицата, можете да очаквате прилична до масивна печалба в производителността. -
Увеличете
work_memпараметър за тази една операция сSETкоманда толкова високо, колкото можете. Колкото повече памет може да използва хеш операцията, толкова по-бърза ще бъде. С толкова голяма таблица вероятно пак ще имате временни файлове, но все пак можете да очаквате прилично увеличение на производителността. -
Увеличете
checkpoint_segments(илиmax_wal_sizeот версия 9.6 нататък) до висока стойност, така че да има по-малко контролни точки по време наUPDATEоперация. -
Уверете се, че статистическите данни на таблицата и за двете таблици са точни, така че PostgreSQL да може да направи добра оценка за броя на хеш-кофите за създаване.
След UPDATE , ако засяга голям брой редове, можете да обмислите да изпълните VACUUM (FULL) на tx_input1 за да се отървете от полученото подуване на масата. Това ще заключи масата за по-дълго време, така че го направете по време на прозорец за поддръжка. Това ще намали размера на таблицата и като следствие ще ускори последователните сканирания.
