emctl,

В двух словах, без отсылки к первоисточникам :)

У DB2-хи есть два вида партиционирования.
1. размазывание таблицы по разным узлам кластера (требуется DB2 Partitioning Feature) с тем, что каждый обрабатывает свой кусок (при объединении двух таких таблиц обработка происходит распределённо, общение узлов - "каждый с каждым", хотя и есть координирующий "мастер" узел, который для разных коннектов может быть различен; тут главная задача - равномерно размазать и по возможности обеспечить collocation данных).
Видимо речь не о нём.

2. Разделение таблицы на партиции в рамках одной ноды/stand-alone сервера (в общем то же, что и у Оракла).
Что даёт:
1. Ну, простое удобство по частям добавлять/откусывать партиции (в архив там данные отправлять, прочий maintenance осуществлять).
2. Возможность на массовых вставках работать с индексами значительно меньшего размера (sic!)
3. В определённых случаях получать table scan'ы не по всей таблице, а по небольшим частям, т.е. получать пользу от частично отсортированных данных (join'ить по кусочкам при join'е по партиционному ключу и т.д.)
4. При включённом внутри-партиционном параллелизме возможность параллельно выполнять подзапросы (выполняющиеся в рамках одного запроса) на разных частях таблицы (которые в свою очередь можно распихать по разным физическим stotage'ам, впрочем, как и одну партицию). На самом деле сомнительное удовольствие, но можно, к примеру, отправить "архивную" часть таблицы на "медленные" диски и вообще по-разному извращаться.
Наверное всё.

Работа (update) с некоторым заданным set'ом заказов (пусть и большим) вообще партиционированности таблицы ортогональна.
Партиционированность - на уровень выше уровня физического хранения, по сему может быть абсолютно не влияющей на указанную ситуацию (а при должном старании может оказаться влияющей отрицательно).

Если выборка идёт прямо по индексу, то нам абсолютно наплевать на партиционированность.
Если по диапазону значений (дат, ID), то скан части большого индекса может быть ничуть не не хуже скана индекса индивидуальной партиции.
Выигрыш, когда партиционирование даёт реальный прирост в скорости - ситуация, когда table scan по партиции эффективней чего-либо другого (нужно перебрать достаточно большое количество записей, но есть предикат, указывающий, что нужна только такая-то (такие-то) партиция(и)).

Далее, уже на физическом уровне, можно постараться физически положить совместно используемые записи близко друг к другу.
См. пара картинок про кластерные индексы и про prefetch .
Что, впрочем, тоже может никак не помогать, если нужные записи расположены достаточно далеко друг от друга.

Ну, про Multi-Dimentional Clustering уже упоминалось.


В итоге, вcё зависит от того как выбираются требуемые записи (по одной/скопом), общего их количества, процента выбираемых и т.п.

Partitioning по дате как правило один из самых естественных, при этом даже если они вместе с ID монотонно возрастают, partitioning по ID выглядит сомнительным, если только у нас нет запросов на выборку по диапазону ID.

Т.е. по-моему никакого недопонимания нет. Возможно недопонимание возникло у советчиков - партиционирование таблицы внутри ноды (как замена стандартному паттерну "сделать множество таблиц и объединить их одним вью") появилось в DB2 заметно позднее партиционирования на кластере (которому уже ну не менее 15 лет).

Тонкие отличия с Ораклом начинаются в обработке параметризованных запросов и Bind Variable Peeking, где параметр является партиционным ключом.