Funny_Falcon Hordi10 таблиц быстрее
Правда? Могу поверить, если какой-то запрос сваливается в seqscan.
Люди убедите меня что это правда в любом случае!!!
А то у меня таблица, в ней пока только за 2 месяца данные. Не хочу наступить на грабли месяца через три.
Грабли, увеличиваюшщиеся с увеличением таблицы:
1. Запросы падающие на seqscan. Т.е. это count(), да пожалуй и все.
2. Увеличение размеров btree индексов.
Проблемы:
1. Увеличивает время поиска по бинарному дереву за счет увеличения кол-ва записей ( впрочем не на много ln(n) -это савсем мало 10 раз это 2^4 т.е. на 4 шага - мелочи) .
2. Увеличение страниц индекса - это уже посерьезнее, больше IO на чтение, больше памяти на кеширование. К сожалению как раз в 10 раз.
Решение:
1. Партиционные индексы таки рулят :), и могут реально избавить от его увеличения. А то что их будет 10 - ну, это совсем не страшно.
3. Увеличение места занимаемго таблицей:
Проблемы:
1. А все таже с страницами при поиске, просмотре и выборке.Падение быстродействия - ХЗ, зависит от размера записи
2. Увеличение времени обслуживания СУБД т.е. vacuum, analyze и т.д.
3. Возможно ухудшение статистики
Решение:
1. А никак ИМХО.
2. Памяти и побольше.
3. А никак ИМХО.
Больше я проблем не вижу.

Funny_Falcon Hordi10 таблиц быстрее
Правда? Могу поверить, если какой-то запрос сваливается в seqscan.
Люди убедите меня что это правда в любом случае!!!
А то у меня таблица, в ней пока только за 2 месяца данные. Не хочу наступить на грабли месяца через три.
А вердикт простой - таки медление. А вот на сколько - глубокий филосовский вопрос. ИМХО - незначительно. Впрочем при малых объемах памяти может наступить коммунизм (например для MS SQL как только для JOINов не хватает памяти падение быстродействие в несколько раз, и я не думаю, что у постгреса с этим сильно лучше).