Честно говоря, не уверен, что план запроса в этом случае чем-то поможет, поэтому не стал загромождать и без того довольно длинную заметку. Но все это можно легко повторить самостоятельно и посмотреть любые планы.
Насчет 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 не знал, спасибо!
Оракловый оптимизатор, без всякого сомнения, на порядок более сложно устроен и умеет много такого, до чего Постгресу расти еще очень долго — там пока все довольно просто. Но он растет.
Глобального кэша не существует, подготовленные операторы живут в памяти процессов, обслуживающих соединения.
С другой стороны, отсутствие глобального кэша удешевляет разбор.
А насчет того, можно или нельзя строить высоконагруженные системы — это надо тестировать и смотреть, я так считаю.
PL/pgSQL всегда использует подготовленные операторы, это да. То есть можно сказать, что всегда кэшируется разобранный запрос. Но разобранный запрос — это еще не план. План будет строиться каждый раз заново до тех пор, пока планировщик не сочтет, что «общий» план не хуже тех «частных», которые он до сих пор строил.
Честно говоря, не уверен, что план запроса в этом случае чем-то поможет, поэтому не стал загромождать и без того довольно длинную заметку. Но все это можно легко повторить самостоятельно и посмотреть любые планы.
Насчет 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.
Оракловый оптимизатор, без всякого сомнения, на порядок более сложно устроен и умеет много такого, до чего Постгресу расти еще очень долго — там пока все довольно просто. Но он растет.
С другой стороны, отсутствие глобального кэша удешевляет разбор.
А насчет того, можно или нельзя строить высоконагруженные системы — это надо тестировать и смотреть, я так считаю.