>> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.>
> Это вы мне говорите, человеку с 20-летним стажем работы с СУБД?FYI: стаж != экспертиза
> Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например).
Как бы да. Когда сам знаешь, где разбросаны грабли, ты их обходишь. Как я говорил, основной оптимизатор SQL-запроса этот запрос пишет.
А оптимизаторы ошибаются. И иногда не просто ошибаются, а даже обсираются. Оптимизаторы очень не любят большое число JOIN на одном уровне -- Oracle не шмог в похожет случае.
Кстати, основная причина промаха оптимизатора -- некорректная оценка мощности множества.
> Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату).
Вот отсюда подробнее. Где они там машинное обучение всунули, и, главное, зачем. Предоставьте пруфы.
> Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами.
Ну вообще да, в 99% случаев они неплохо справляются, если самому на грабли не наступать.
> А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения.
Я не говорю о том, что оптимизатор не может вообще ничего. И я согласен, оптимизаторы становятся всё умнее (или менее глупыми. Была ржака как-то -- в оптимизаторе MySQL нашли место, где rvalue не вычислялся на момент анализа запроса, хотя все данные для этого были). Оптимизаторы действительно творят невозможное. Помнится, запрос по временному ряду был очень весело ограничен: `WHERE TRUNC(event_created, 'MM') = :event_month` -- так вот, оптимизатор тут таки шмог, и вместо ожидаемого TABLE FULL ACCESS внезапно был INDEX RANGE SCAN. Да, он вычитал занные за весь год, но это сильно лучше полного чтения таблицы.
Но ещё раз -- оптимизатор -- это программа, она не может ничего "выдумать". Задача оптимизатора -- сократить число чтений. Принятие же решения по сути является задачей поиска минимума. Он способен перебрать ограниченное число вариантов -- не больше, чем в него заложил программист. Оптимизатор, каким бы "умным" он ни был, останется тупеньким конечным автоматом. И очень странно, что я об этом рассказываю человеку, у которого "20 лет стажа работы с СУБД"
