Как оценивать замедление базы от добавления дополнительных индексов?

Индекс для count() здесь, по-моему, - извращение, т.е., как вы и сказали, «тупо». Не проще ли и удобнее добавить новую колонку в таблицу разделов, с триггером на добавление/удаление поста?

Вопрос именно про влияние индексов на добавление. Ну интересно мне :)

Триггеры это конечно здорово, но на монге их нет, и возможны нюансы при шардинге. У меня уже написана денормализация, и я хочу ее выпилить, заменив на кешированные запросы, чтобы упростить код. Это тот случай, когда тупое решение удобнее :)

Говорят, postgresql быстрее будет.

она может оказаться не линейной, индексы на больших таблицах (у нас было около 100гб) раздувают размер бд (у нас было до 300гб) - при этом постгрес вполне манипулировал сим безобразием на не большом сервачке, но

в постгресе есть отложенная генерация индексов и некоторые другие плюшки

Ок. Поправка - считаем что индекс полностью влазит в память.

Индекс композитный, по 2 полям - ID форума и состояние поста (видимый, удаленный и т.п.). Oтличие от других индексов - фиговая cardinality.

Доступ к индексу при обновлении строки базовой таблицы это обычно index exact scan, поскольку субд знает значения всех индексированных колонок и rowid строки базовой таблицы. Для btree индексов сложность доступа логарифмическая от колва строк. Селективность индекса не влияет на сложность доступа, так как при обновлении индекса всегда известен rowid обновляемой строки таблицы.

Так что каждый индекс замедляет операции изменения таблицы примерно одинаково. Если только индекс не по колонке с преобладанием null значений.

Спасибо большое.

А не подскажете еще по скорости count? Видел цифры, что в монге на 10 миллионах строк сount() занимает 0.2 секунды. Это нормально вообще? Думал что будет быстрее.

Если считать все строки таблицы, то субд делает full table scan или fast full index scan по индексу, содержащему not null столбцы. Это не быстро, трудоемкость линейная.

Если подсчитывать строки, отвечающие условию, то субд может выбрать индекс, такой, что подсчитать искомые строки можно с помощью index range scan. Трудоемкость тоже линейная, но не от всех строк таблицы, а от строк, отвечающих условию.

Например таблица сообщений форума с полями номер, раздел, текст, индексом по полю раздел. Колво сообщений в заданном разделе можно посчитать с использованием доступа index range scan.

Конкретные цифры скорости зависят. Например в своем блоге Кевин Клоссон показывал, как оракл делает фулл скан с диска с пропускной способностью 5GB/s. Если все в памяти то делишь объем индекса или таблицы на пропускную способность памяти и получаешь примерную оценку.

Ну тут так - индекс в памяти, count по index range scan, но итоговое значение около 1 миллиона. Хочется понять, 1 миллион строк в один поток за ~1 миллисекунду реально «сложить» или я чего-то запредельное хочу.

Попробую базу тестовыми данными забить и посмотреть.