1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
WITH stat_index_uses AS (
SELECT distinct
i.indexname,
i.tablename,
i.schemaname,
i.indexdef,
SUM(pg_relation_size(indexrelid)) OVER (PARTITION BY indexname) as index_size,
split_part(i.indexdef, 'USING ', 2) as indexdef_part ,
s.idx_scan,
-- статистика чтения индекса
SUM(s.idx_scan) OVER (PARTITION BY i.tablename) AS tdx_scan -- если статистика по таблице в целом равна 0 значит статистика не создавалась, такие индексы не удаляем
FROM
pg_indexes i
LEFT JOIN pg_stat_user_indexes s ON s.indexrelname = i.indexname
WHERE
i.tablename = 'TABLICAAA'
AND i.schemaname = 'public'
) SELECT
tdx_scan as tab_scan,
index_size as ind_size,
pg_relation_size(schemaname||'.'||tablename) as tab_size,
pg_total_relation_size(schemaname||'.'||tablename) as tab_total_size_befor,
0 as tab_total_size_after,
current_date as dt,
'drop' as action,
schemaname as schemaname,
tablename as tablename,
indexname as indexname,
'201702220900_drop_index__TABLICAA' as changelog,
'изменение индекса' as descr,
indexdef as def,
indexdef_part as def_part
FROM
stat_index_uses i
WHERE
split_part(i.indexdef, 'USING ', 2) = 'btree (is_system) WHERE (is_system = false)'
--AND i.idx_scan < 10
--AND i.tdx_scan > 10000
пришлось поставить distinct и оконку на pg_relation_size(indexrelid)
а в целом скрипт чистил подозрительные индексы - генерил скрипт на удаление (это правда дальше обрабатывалось)
и заодно попутно собирал статистику
ченжсет навернулся на том что для одного индекса вернулось две строки (отличие именно в размере индекса)
и соответственно далее два индекса должно было удалится, первый удалился, а второй он же дал исключение
сейчас строки не дублируются
может это не из за pg_relation_size(indexrelid)
кто знает, а может есть недокументированный баг в этой функции, и я единственный кто его словил(
