У меня тут запрос после 2ух дней работы лег, я приуныл слегка... Разбил данные на 300 кусков (по 100к строк) и в 15 потоков запустил. Харды еле шуршат, может посоветуете как более оптимально написать запрос?
Я выбрал дубли в отдельную таблицу и запилил удаление:
egrip=# explain delete from egrip_versions v USING dups_ip2 where dups_ip2.ogrn = v.ogrn and dups_ip2.checksum = v.checksum and v.version < dups_ip2.ver and v.ogrn >= 0 and v.ogrn <= 10;
Delete on egrip_versions v (cost=1.13..17.30 rows=1 width=12)
-> Nested Loop (cost=1.13..17.30 rows=1 width=12)
-> Index Scan using egrip_versions_ogrn_version_idx on egrip_versions v (cost=0.57..8.59 rows=1 width=51)
Index Cond: ((ogrn >= 0) AND (ogrn <= 10))
-> Index Scan using dups_ip2_ogrn_idx on dups_ip2 (cost=0.56..8.70 rows=1 width=51)
Index Cond: (ogrn = v.ogrn)
Filter: ((v.version < ver) AND (v.checksum = checksum))
(7 rows)
Но у меня 100к строк удаляются где-то по часу (на 100к - 140к дублей)
Странный план какой-то, на первый взгляд (оценки странные; и похоже, что индексы тут не оптимальные). Вы делали VACUUM ANALYZE каждой из этих таблиц? А, ещё: > Разбил данные на 300 кусков (по 100к строк) и в 15 потоков запустил. Какие данные / как "разбили" (мне, например, непонятно)?
дробить на кусочки, которые за 2-5 минут отрабатывают (10к, скажем) и в несколько потоков
может перелить в новую таблицу с уникальным индексом по ним и on conflict do nothing?
Обсуждают сегодня