Comments 4
Спасибо за пост, картинки радуют глаз!
После 12 лет с Oracle мне временами ужасно не хватает хинтов в Postgres. Но это ничего, все равно добро (opensource) в итоге победит, и я верю что Postgres станет лидером среди RDBMS.
Если желаете подробностей о том, как происходит оценка плана и рассчитывается стоимость каждого шага, рекомендую обратиться к Главе 3 книги «The Internals of PostgreSQL». Книга изначально была написана на японском, но автор постепенно переводит ее на английский и выкладывает на своем персональном сайте. До сих пор это лучший материал по Postgres что я встречал с сети.
После 12 лет с Oracle мне временами ужасно не хватает хинтов в Postgres. Но это ничего, все равно добро (opensource) в итоге победит, и я верю что Postgres станет лидером среди RDBMS.
Если желаете подробностей о том, как происходит оценка плана и рассчитывается стоимость каждого шага, рекомендую обратиться к Главе 3 книги «The Internals of PostgreSQL». Книга изначально была написана на японском, но автор постепенно переводит ее на английский и выкладывает на своем персональном сайте. До сих пор это лучший материал по Postgres что я встречал с сети.
Спасибо за статью!
Если таблицы объединяются по индексу (а в подавляющем большинстве реальных запросов это именно так) то nested loop будет работать не полным перебором, а именно через индекс. Это снижает сложность c nm до nlog(m). Поэтому, как правило, nested loop как раз таки является самым эффективным алгоритмом.
Картинка с графиками вычислительной сложности алгоритмов соединения — лучшее и самое наглядное объяснение работы планировщика, что я видел.
Sign up to leave a comment.
Сюрпризы планировщика запросов в БД PostgreSQL