qwwqкто--нибудь проверял руками вот эту идею:

http://postgresql.nabble.com/nested-partitioning-td5771414.html

т.е. можно ли урезать деревом предков, с inherits констрайнтами область перебора планировшиком ? или он всё равно полезет до самого листового уровня, наплевав на веточное наследуемое ограничение (а зачем) ?

я конечно соберу на коленке тест--кейс, но наверняка наперёд известно, как там у неё унутре неонка и думатель того-этого

Собирал тест кейс, проверяли исходники.
Сначала строится полное дерево всех наследуемых таблиц и только потом начинается сверка check-ов.
Так что, увы, не поможет.

qwwqПавел Лузанов,

спасибо,
начал собирать кейс -- столкнулся с тем, что надо чем-то смотреть за внутренней жизнью. т.к. EXPLAIN показывает только её результат.
остался факультативный вопрос -- чем смотрели за кишками ?

/т.е. можно загнать величины в астрономию, и смотреть вид зависимости, но это косвенное измерение/



и ещё вопрос -- какова зависимость времени планирования от числа наличных индексов ?
тут кто--то бился с апдейтом, время планирования которого было велико, не смотря на явное указание партиционного ограничения
и чем больше индексов -- тем печальнее
есть в исходниках что-то , что бы подтверждало
Смотрел величины в "астрономии", косвенно убедился, что ускорения нет.
Смотрел так.
На двух секциях по одной строке в каждой - запрос выполняется моментально, как и ожидалось.
На 3-х тысячах секций - ответ ~1 секунда. Запомним его.
Возвращаемся к двум секциям и первую из них делаем родительской для еще 3-х тысяч таблиц.
Условие check для всех 3-х тысяч лежит внутри условия для 1-й секции.
Делаем запрос ко второй секции в надежде, что планировщик, убедившись что первая секция не проходит по check, не полезет во все 3 тысячи ее потомков, но время выполнения всё та же ~1 секунда (там даже десятые доли секунды совпадали).

После этого проверили исходники и убедились, что ждать ускорения не стоит.

Влияние индексов на время планирования не смотрел, поэтому врать не буду.