Есть таблица около 20 млн записей. В ней 5 индексов.
1) данные в колонке char 32, потом будет заполнен весь, но хз когда это будет. индекс занимает 2564 мб
2) данные в колонке char 32, потом будет заполнен на половину, но хз когда это будет. индекс занимает 2529 мб
сейчас где то миллиона полтора записей заполнено в 1 колонке и 700 тысяч во второй.
3) данные в колонке char var 255, заполнен 100% уникальными записями. индекс занимает 2028 мб.
4) данные в колонке char 16, очень мало данных, типа 1 запись на тысячу пустых. индекс занимает 1758 мб
5) данные в колонке char 10, заполнен данными 100%, но не уникальные значения (несколько сотен строк). индекс занимает 580 мб.
Размеры: таблица 8615 мб; toast 8680 кб; размер индексов 12 гб!!!
Вопросы: Это нормально такие индексы? Есть ли смысл ставить другие типы индексов под мою задачу (не btree)?

авторв пж поля типа char (не чар(1)) всё сказал г-н лавров
а пж это кто?
я посмотрел в pgadmin у меня колонки character и указана длинна. Это не правильно?
автору вас там что -- джейсоны или иксемель ?
qwwq, не уверен. Если json - данные для людей, а второе xml - то скажу что у меня. 1 и 2 колонка - это мд5 сумма файлов; 3 колонка - это url (только домен и зона, без протокола). это цифровой код, записанный текстом (так как он логично нужен текстом) и 5 колонка - это дата дд.мм.гггг - так как она мне нужна для обработки всё равно только текстом. Это какой тип данных json?
авторставьте плановый реиндекс на каждый 100 тыс -- 1 лям апдейтов, что ли.
то есть команду
ALTER INDEX [ IF EXISTS ] имя RENAME TO новое_имя
а вот товарищ пишет
авторпри наличии 5 индексов в таблице это вполне нормально что в сумме они будут занимать больше чем таблица (особенно если сама таблица узкая).
и еще подскажите, пожалуйста, а как reindex сделать, чтобы он таблицу не блокировал?
---
авторпосле того как вы в таблицу добавили новое поле с default значением - у вас таблицам и индексы выросли в 2 раза автоматически (и с хорошими шансами будут расти дальше по мере добавления новых колонок таким странным методом).
Maxim Boguk, то есть это плохо NULL убирать. Но я наоборот читаю, что любое значение null также занимает место, особенно на boolean всяких. Опять же мне условия выборок упрощаются в написании, мне не надо писать WHERE znak = null OR znak = '' чтобы найти все пустые значения, а достаточно набрать WHERE znak = ''
Я не прав?
авторРекомендую посмотреть в сторону pgcompacttable или pg_reorg (или старого доброго vacuum full если у вас относительно свежая версия базы), и посмотреть на baseline размер таблицы и индексов (а не на текущие распухшие вашими стараниями значения).
почитал. Ничего не понял.
авторNULL значения в поле тоже индексируются если вы не сделали специально условный индекс по NOT NULL то ваши незаполненные значения будут в индексе.
а можно при создании индекса указать, чтобы постгрес значения '' не индексировал? Или какие то определенные значения?

авторс этим закончили.
я ничего не понял, но пофиг.
автороткуда ж, любезный, у вас там тосты взялись, на 5 коротких полях ?
в таблице 14 колонок, это индексов 5. Я перечислил только колонки в которых есть индексы. У меня в этой таблице есть поле text, как правило мелкое, килобайт - два.
Если запись обрабатывается, то в поле text обязательно чо то записывается (99.9%). Или я строку удаляю потом.
авторну и т.д.
я ничего не понял, но пофиг.

Alexius, спасибо. Создал командой:



вместо старого индекса размером 2529 мб, получился индекс 1069 мб.
То есть мне надо после удаления 1 млн записей пересоздавать индексы, удаляя старые - верно? Или как то иначе?
Я верно понимаю, что в индексе на 1000 мб скорость будет в два раза быстрее записи, чем в индексе на 2000 мб?

Alexius, спасибо за ответ.
Хотя мне это не кажется очень удобным, но правильно ли я понял, что с базами в несколько гигабайт, на которых активно ведется добавление новых записей и удаление старых все администраторы так и делают:
1. создают новый индекс с новым именем;
2. удаляют старый индекс.
И так каждые две недели к примеру?
Второй вопрос. У меня на ssd 51 гб свободен, может как то симплинками перенести индексы на ssd? Или у меня на компьютере 32 гб оперативной памяти, правда 21 гб занят программами. Может как то увеличить оперативную память для индексов?
зы
хотя честно говоря сейчас скорости на выборку мне более чем хватает.

---
сбор отчета отработал почти в 5 раз быстрее (вместо 5+ минут - 1 минута). Обработка записей (основной процесс) обработал всего на несколько процентов больше (вместо 240 тысяч - 256 тысяч записей). Может быть это из-за индексов.

vyegorov, огромное вам спасибо. Теперь всё понятно.