Всем привет, подскажите, пожалуйста, может кто знает. Странную штуку наблюдаю, такой

Question

Всем привет, подскажите, пожалуйста, может кто знает. Странную штуку наблюдаю, такой

запрос занял вот больше 6 часов для 10 млн
=> update contracts set cm_states_len=array_length(cm_states, 1);
UPDATE 10932021
Time: 22922672.221 ms (06:22:02.672)
где cm_states - это int[], средняя длина где-то 3.

но при этом такой запрос, который тоже все данные обновляет занимает всего 16 минут
=> update contracts set cm_from_to=('[' || fromDate::text || ',' || toDate::text || ']')::daterange where fromDate<=toDate;
UPDATE 10925814
Time: 978479.272 ms (16:18.479)

select array_length(cm_states, 1)... для 100к строк работает за секунды, поэтому это явно не тяжелая операция.
Индексов на поле cm_states_len нету, на cm_states есть GIN индекс.

Так почему же первый запрос работал так долго?

#backend #devops #pgsql #programming #russian

0

19.07.2019

4 ответов

14 просмотров

Михаил Шурутов

Первый запрос поднимал данные с диска, второй молотил по кешам, как ФС, таки и самого ПГ.

0

19.07.2019

Andrey Anshin

Немного не по самому вопросу >('[' || fromDate::text || ',' || toDate::text || ']')::daterange чота сложнА, можно ведь daterange(fromDate, toDate, '[]')

0

19.07.2019

Yaroslav Schekin

Да более того, у Вас есть индекс на этот cm_from_to, но он всё равно быстрее: "contracts_cm_from_to_idx" gist (cm_from_to) Может быть, Вы это cm_states_len только добавили, и все значения были NULL? В таком случае, UPDATE мог вызвать перезапись всей таблицы и перестороение всех индексов (c extension всего этого), после чего прочие UPDATE уже могут работать побыстрее ("свободного" места в heap/индексах теперь много).

0

19.07.2019

Yurimaru · Accepted Answer

Yurimaru

А план?

0

19.07.2019

172 похожих чатов

Всем привет, подскажите, пожалуйста, может кто знает. Странную штуку наблюдаю, такой

4 ответов

Похожие вопросы