А суть секционирования разбить секции чтобы работать с одной маленькой?

или разбить так чтобы работать распределенно с разными?

Чтобы не работать с ненужными.

В том, чтобы проще было обслуживать — добавлять секции с подготовленными данными, выполнять массовое удаление (отключением или удалением секций), (пере)создавать индексы (секции дают возможность делать это "по частям") и тому подобное (виды обслуживания зависят от используемой СУБД).

В базе это всеж partition pruning, если тот же клик не вспоминать

Я не понимаю, что Вы имеете в виду под "в базе это всеж partition pruning", извините.

Исключение частей данных из процедуры выборки данных по ключу партиционирлвания на основе фильтра в запросе.

"— А гвозди? — Вот жэ они!"

Я знаю, что такое partition pruning. Я не понимаю, что Вы имели в виду своим сообщением, потому что partition pruning (почти во всех случаях в адекватно реализованных СУБД современной архитектуры) — это способ сделать так, чтобы от партиционирования производительность совсем уж не проваливалась (при прочих равных).

Причём тут "не проваливалась"? От исключения партиций скорость выполнения запросов увеличивается. Всё остальные опции (присоединение/отключенике/обмен/докализация индексов) - это уже дополнительные бенефиты, зависящее от СУБД. В GP, например, используется только обмен, индексы там никому особо не нужны. В КХ разреженный PI тоже по всем данным. Основная задача партиционирования - сократить объем выборки до начала работы с данными на диске.

> Причём тут "не проваливалась"? При том, что если бы его не было, скорость многих запросов была бы гораздо хуже (по сравнению с аналогичной непартционированной таблицей) — если не считать СУБД-специфичных эффектов (связанных, опять-таки, с maintenance). > От исключения партиций скорость выполнения запросов увеличивается. Ага. Вопрос в том, по сравнению конкретно с чем. > это уже дополнительные бенефиты Да нет, это именно то, ради чего оно нужно, реализуется в СУБД, и используется их [грамотными] пользователями. Кстати, в некоторых СУБД партиционированная таблица почти всегда проиграет по производительности запросов к ней аналогичной обычной таблице (с теми же данными, индексами и т.п.) при условии того, что та и другая только что созданы. Более того, это, как раз, нормальная ситуация (исходя из основ теории архитектуры СУБД). Тем не менее, партиционирование в таких СУБД используют всё равно — с целью получить его реальные преимущества. > Основная задача партиционирования - сократить объем выборки до начала работы с данными на диске. Для этого в СУБД существуют индексы, а не этот убогий костыль. ;)

Вообще с одной стороны верные утверждения, а с другой стороны они накладываются не на асе технологии. Те же партиции верны для гп, где индексы используют только отбитые или специфичные пользователи. Нюанс в том, что предлагаемая теория СУБД это фигня вырванная из контекста

Хмм... это, отчасти, верно. Если из-за каких-то дефектов ограничений используемой технологии эффективно реализовать на её основе лучшие в общем случае алгоритмы и методы доступа не представляется возможным, то придётся использовать менее эффективные в общем случае, но работающие в данных ограничениях, что поделаешь. В качестве иллюстрации — мне вспоминается, что в какой-то задаче из TAOCP (третьего тома, "Сортировка и поиск") требовалось доказать, что на машинах с т.н. барабанной [оперативной] памятью bubble sort (за O(n²)!) асимптотически оптимальна (т.е. все "стандартные" методы, которые обычно работают за O(n log n) , там бесполезны / у них асимптотика как минимум не лучше). > Нюанс в том, что предлагаемая теория СУБД это фигня вырванная из контекста Я бы так не сказал — просто необычные ограничения её мало интересуют (по понятным причинам), это да (но см. выше). ;)

Суть секционирования таблиц - это морковка перед мордой осла.

Во, я был прав..

Я почему то подумал что секционированием можно решить проблему локов, если идеально разделить секции мб субд умеет лочить только одну секцию