Можно сэкономить, используя тот факт, что если построен кротчайший путь из A в B, проходящий через C, то и часть этого пути от A до C тоже будет кротчайшей. Посмотрите алгоритм Дейкстры.
Честно говоря, не уверен, что план запроса в этом случае чем-то поможет, поэтому не стал загромождать и без того довольно длинную заметку. Но все это можно легко повторить самостоятельно и посмотреть любые планы.
Насчет ltree + gin gist — почему бы и нет, если перелеты статические, а искать надо часто. И к тому же как-нибудь хитро, типа «из A в B через C», потому что иначе достаточно обычного индекса.
Если говорить формально, то так: найти минимальное число N такое, что из произвольного аэропорта A можно добраться в произвольный аэропорт B, используя меньшее либо равное N число пересадок.
То есть нас интересует число пересадок, которое потребуется в худшем случае. Поэтому надо найти кротчайшие пути для всех пар аэропортов и выбрать из них максимальный.
Насчет литературы… Специальной книги про SQL именно для Постгреса, боюсь, пока не существует. Да и вообще сейчас с книгами про Постгрес на русском беда — есть что-то переводное, и то так себе.
Но вообще можно читать любую книгу про SQL, которых тысячи. Постгрес весьма близок к стандарту, так что проблем не должно быть. Порекомендовать что-то конкретное не готов, но можно попробовать сориентироваться по ассортименту приличных издательств и отзывам. Ну, как вариант.
Сделайте set search_path = bookings, public;
Если поможет (должно), то, чтобы каждый раз не набрать эту команду, можно сделать один раз alter database demo set search_path = bookings, public;
Я, увы, тоже не знаю такого инструмента. Правда, мне лично никогда и не нужна была программа, чтобы менять схему БД — я по-старинке считаю, что это надо делать скриптами, а не мышкой.
Но что совсем смешно, я до сих пор не смог найти даже инструмент, чтобы просто удобно рисовать ER-диаграммы, вообще без всякой привязки к конкретной БД.
А картинка в статье от безысходности нарисована руками в LibreOffice.
О, хинты — это больная тема… Разработчики оптимизатора не хотят их добавлять (и их в принципе можно понять, по моему опыту хинты часто втыкают просто от нежелания разобраться и найти нормальное решение), но есть расширения на эту тему.
Про v$sql_cs_histogram не знал, спасибо!
Оракловый оптимизатор, без всякого сомнения, на порядок более сложно устроен и умеет много такого, до чего Постгресу расти еще очень долго — там пока все довольно просто. Но он растет.
Глобального кэша не существует, подготовленные операторы живут в памяти процессов, обслуживающих соединения.
С другой стороны, отсутствие глобального кэша удешевляет разбор.
А насчет того, можно или нельзя строить высоконагруженные системы — это надо тестировать и смотреть, я так считаю.
Всегда пожалуйста. Продолжение следует.
Оставайтесь с нами!
Если это единственное замечание к статье, то я удовлетворен (:
Совершенно верно.
Спасибо, Дим. Дальше — больше.
Можно сэкономить, используя тот факт, что если построен кротчайший путь из A в B, проходящий через C, то и часть этого пути от A до C тоже будет кротчайшей. Посмотрите алгоритм Дейкстры.
Честно говоря, не уверен, что план запроса в этом случае чем-то поможет, поэтому не стал загромождать и без того довольно длинную заметку. Но все это можно легко повторить самостоятельно и посмотреть любые планы.
Насчет ltree +
gingist — почему бы и нет, если перелеты статические, а искать надо часто. И к тому же как-нибудь хитро, типа «из A в B через C», потому что иначе достаточно обычного индекса.Если говорить формально, то так: найти минимальное число N такое, что из произвольного аэропорта A можно добраться в произвольный аэропорт B, используя меньшее либо равное N число пересадок.
То есть нас интересует число пересадок, которое потребуется в худшем случае. Поэтому надо найти кротчайшие пути для всех пар аэропортов и выбрать из них максимальный.
А в демо-базе все равно только самолеты.
А в демо-базе все равно только самолеты.
Пользуйтесь на здоровье.
Насчет литературы… Специальной книги про SQL именно для Постгреса, боюсь, пока не существует. Да и вообще сейчас с книгами про Постгрес на русском беда — есть что-то переводное, и то так себе.
Но вообще можно читать любую книгу про SQL, которых тысячи. Постгрес весьма близок к стандарту, так что проблем не должно быть. Порекомендовать что-то конкретное не готов, но можно попробовать сориентироваться по ассортименту приличных издательств и отзывам. Ну, как вариант.
Спасибо, подумаем.
Сделайте
set search_path = bookings, public;
Если поможет (должно), то, чтобы каждый раз не набрать эту команду, можно сделать один раз
alter database demo set search_path = bookings, public;
Она должна без проблем загрузиться на любую версию, начиная с 9.4.
А для Постгиса мы вряд ли сделаем свою демо-базу. Тем более, что там вроде есть над чем развлекаться (взять какой-нибудь openstreetmap).
Спасибо. Полнотекстовый поиск Постгрес умеет, напишем со временем и про него.
Я, увы, тоже не знаю такого инструмента. Правда, мне лично никогда и не нужна была программа, чтобы менять схему БД — я по-старинке считаю, что это надо делать скриптами, а не мышкой.
Но что совсем смешно, я до сих пор не смог найти даже инструмент, чтобы просто удобно рисовать ER-диаграммы, вообще без всякой привязки к конкретной БД.
А картинка в статье от безысходности нарисована руками в LibreOffice.
Оракловый оптимизатор, без всякого сомнения, на порядок более сложно устроен и умеет много такого, до чего Постгресу расти еще очень долго — там пока все довольно просто. Но он растет.
С другой стороны, отсутствие глобального кэша удешевляет разбор.
А насчет того, можно или нельзя строить высоконагруженные системы — это надо тестировать и смотреть, я так считаю.