У меня была аналогичная ситуация с Телекомами. DBA часто ставились перед фактом
что всё плохо, и надо что-то делать. AWR и Statspack собирали много раз и анализировали.
Очень много аналитических и агрегирующих запросов типа GROUP BY ... HAVING ... ORDER..
Проиндексированы и соптимизированы с помощью SqlTune. Ничего не помогает.
Всё медленно. Всё сводилось к мысли что надо переписывать бизнес-логику.

Но к сожалению взаимодействие между сектором ДБА и разработки не было налажено.
Можно было поговорить по телефону с разработчиком но у него был свой стек
начальников который всячески блокировал любую постороннюю активность.

И вобщем все начинания и процессы оптимизации стопорились на уровне
нежелания разработчика вникать в суть оптимизации. Дескыть вы - ДБА
ваша проблема. А динамический билдер запросов который был вшит в клиента
и который позволял формировать совершенно невообразимые курсоры
до сих пор работает и флудит плохими планами.

Уже увольняясь с телекомов я писал письма с предложениями по внеднению
OLAP-подходов, но всем было пох. Думаю что так всё и осталось.

Q.Tarantinoв подобных случаях недовольных пользователей надо отправлять к разработчикам. пусть они с ними общаются.
Я не хочу сворачивать в не-техническую тему. И также не хочу палить контору.
Но шишки всё равно доставались ДБА (сектору эксплуатации). Таково было
положение вещей.

Сергей АрсеньевDimitry SibiryakovХорошо, что сказали Вы это. Потому что теперь могу я свободно пальцем ткнуть в оффтопик,
где NULL ноды хранятся в B*tree индексе

Забавно, но NULLы можно заставить хранить и ORACLE в составном индексе.
Как и в PG добавить в индекс where ... not null и получить как в Oracle.

Спор по этому поводу яйца выеденного не стоит.
NULL-s можно заменить на свою волшебную константу и использовать через NVL.
При этом мы получим как бонус индексирование.

Но я-бы предложил другой подход. Как известно (ох как я люблю эту фразу!)
или "есть общепризнанный факт" что индекс эффективен когда объём выборки
не превышает 7%.

Или еще меньше. Я уж не помню. В разные времена эта цифира была разной.
И чем больше становились базы - тем меньше была эта пропорция.

И вобщем-то принудительное индексирование NULL тяготеет к переосмыслению
этого принципа.

Мы должны индексировать ПОЛЕЗНОЕ.

А пустота - это бесполезное.

Dimitry Sibiryakov, при чём тут Oracle?

Это обычно стоимостное правило для Sequental/Scattered reads.
Основано на физике работы жёсткого диска.

И опять-же... из индекса ничего выкидывать не надо. Правило касается
не размера индекса. А размера выбоки из него.