Здравствуйте, Sinclair, Вы писали:

S>А там, внезапно, в каждом узле хранится много "локальной" информации.

Твоя "локальная информация" имеет строгую иерархическую природу.


S>Например, для пары таблиц, участвующих в Join, там будут храниться конкретные индексы, предикаты, и residuals для этого join.

Смелее, включи воображение.
Ведь ты претендуешь на "разработчика".
Так КАК она будет хранится?


S>И их там как бы дофига, потому что потенциально orders o join manager m on o.managerId = m.id порождает бездну вариантов исполнения.

В указанном виде? ))


S>Грубо говоря, мы можем использовать любой из 5-6 индексов по Manager, потому что а вдруг там в where что-то особенно селективное написано

Прикольный залет, причём, ты уже вроде бы 3-й раз одинаково залетаешь.
Ведь не "вдруг", а на руках полная комбинация всех where.
Эти where часто образуют иерархию, например, where x>100, а потом еще where x>100 and x<1000 и т.д.


S>и любой из 10-15 индексов по order.

За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
Сколько всего таблиц навроде "order" в средней системе?


S>Итого получаем от полусотни до сотни вариантов исполнения этого join.

И это для самой индексированной таблице, аналогов которой единицы штук даже в самых крупных учётных системах.

При том, что про полусотню враки — большая часть вариантов откидываются как заведомо худшие еще на этапе построения всего набора планов.


S>А для вложенных подзапросов там вообще ад и израиль.

Это если плавать в предмете, сорри.
Если на основании предикатов exists, any/all, not in и т.д. — то та же херня что join, вид сбоку, они все через join выразимы.

А если на основании агрегирующих математических ф-ий — то кол-во вариантов планов падает на порядок-другой сразу, бо опять же получается иерархия исполнения всех (сколько бы ни было уровней вложенности) подзапросов.

Я тут рядом как раз разбирал пример с агрегацией+вычислениями:
http://www.rsdn.org/forum/flame.comp/7059865.1


S>Но основная дупа для идеи "компактного представления" ещё и в том, что "внутри" каждого из этих вариантов плана вшиты детали "окружающего" запроса, то есть, если, к примеру, у меня там где-то затесался where ManagerName like @managerNamePrefix+'%', то у меня в аргументах джойна так и будет стоять не index, а результат index scan c соответствующим предикатом.

Пускай стоит.


S>Это означает, что этот вот кусочек плана запроса я не смогу использовать в плане, построенном для другого запроса.

Всё, я сдаюсь.
Коллега, ну это уже упоротость какая-то. ))
План запроса не хранится в виде данных.
Он хранится как код, как ф-ия с параметрами.
Для этого всё и затевалось.
Иерархичность тут проявляется в иерархии вызовов подпрограмм собсно исполнения планов запросов (а не их тупорылой динамической интерпретации, как оно есть сейчас). Итого, вся эта куча подпрограмм вдоль всей иерархии вызова — она многократно повторно используема.

Степень повторного использования можно регулировать через связывания аргументов с константами, т.е. еще на этапе бета-редукции.
При минимальном связывании будет минимальный бинарник, но макимальное кол-во параметров у каждой ф-ии, при максимальном связывании — наоборот.

В классике оптимизации в С++ этим полюсам соответствует оптимизация по размеру бинарника vs оптимизации по эффективности.


S>Шансов на то, что удастся что-то "склеить", т.е. сослаться на один и тот же узел плана запросов несколько раз из разных деревьев, очень мало.

Взял бы ручками да раписал планы вокруг одной и той же комбинации join.
Ты ведь никогда этого не делал, верно?


S>И чем больше размер поддерева, тем больше в нём специфики, и тем меньше шансов на повторное использование.

Я тебя понял.
Улыбнуло.
При исполнении плана дерево тут строго в другую сторону растёт — от примитивных листьев-операций к конкретной сложной операции.
То бишь, каждый лист (в том числе параметрический) принадлежит куче "деревьев"-конкретных планов.


S>Общая экономия будет близка к нулю.

Экономия во-первых не будет нулевой хотя бы потому, что не будет динамики.
Во-вторых, отбросив разницу статики и динамики у нас не будет экономии только тогда, когда каждый индекс каждой таблицы использован только раз в реальных запросах. Не знаю что там говорит твой опыт, но мой говорит строго обратное — индексы вводятся для популярных сценариев доступа к таблице.


S>Так что можно косвенно оценить расходы места под статическую таблицу планов, почитав различные гайды для DBM. Там, где опытные камрады говорят "ну, в принципе 2GB под кэш планов — это немного".

В динамике? Этого даже мало.


S>Причём в кэш попадают исключительно только те планы, которые были реально использованы движком — то есть из наших 50-100 кандидатов на простой join, в кэш попадёт 1.

ИМХО, это может зависеть от конкретной реализации.
Или, например, будет ли это так для параметрического запроса, где выбор конкретного плана зависит от значения параметра?


S>Чтобы хранить прямо все-все-все варианты, нам потребуются сотни гигабайт.

Насос из пальца, однако.
Для сравнения, есть среднейго размера программа на JS, в этой программе куча похожих мест, но все они компилятся движком v8 уникальным образом. После всевозможного джита бинарник в памяти занял порядка 15 метров. Такая же точно программа после нейтивной оптимизации имеет размер сегмента .text порядка 350 KB, т.е. разница примерно в 50 раз.


S>А для тех запросов, где вариантов немного, их и хранить особо незачем — проще построить их на ходу.

Проще чем что?


S>И вот всё это как бы очевидно людям, которые реально занимались оптимизацией реальных SQL запросов как full-time job, а не только единожды сдали 32х часовой курс реляционной алгебры 20 лет назад.

Во-первых, 160 часов минимум. Это для тех, кто не выбрал себе соотв. специализацию.
Кто выбрал, тому еще плюс 60 часов. И да, нет отдельного курса "реляционной алгебры", это всё идёт по технологиям хранения и обработки данных.

И смысл спекулировать часами, если вся вышка идёт порядка 120 часов лекций?
Вообще вся нахрен вышка. ))
Но за 120 часов жизни ты всю вышку не осилишь, верно?
Поэтому её разбивают на аудиторную и самостоятельную работу и потом еще по кучам направлений, некоторые из которых аж на 3-м курсе, что общее кол-во часов переваливает за тысячу.
Понимаешь, к чему я клоню?
Курс РА тоже даётся не сам по себе, а уже на мощной платформе.
Уже до этого была и дискретка, теории множеств, поля/алгебры, компиляторы/интерпретаторы, линейное программирование с минимаксами, теория массового обслуживания и прочее, прочее, прочее.

А так-то да, без понимания происходящего можно было хоть вечно заниматься оптимизацией запросов по принципу научного тыка в чёрный ящик.
Я и сам посвятил несколько лет своей жизни довольно-таки внушительным учётным системам, наелся этого достаточно.
Извини, но про убогость и неповоротливость СУБД образца начала 2000-х знаю не по наслышке.
И что характерно — принципиально мало что поменялось.
Каких-то кучу вещей добавилось (джавы и дотнеты на стороне сервака, кластера и особые режимы репликации и т.д. и т.п.) но в самой базе изменения минимальны до обидного.

Или вот даже коллега IB "удивил" меня тем, что, оказывается, уже лет 10 движки БД умеют распознавать "похожие" некоторые запросы, которые отличаются лишь константой в предикате. И на полном серьёзе думал, что убил этим, даже гнался там за мной и оскорблял. )) При том, что мы как раз обсуждали систему, которая ради именно такой операции и создавалась.

Т.е. должна делать ровно то же самое, но не для "некоторых" запросов, а потенциально для всех.

Чувак даже не потрудился включить голову и сообразить, что раз это МОЖНО делать в статике (я же ему предлагаю именно так делать), то можно попытаться это сделать и в динамике (как перешли от интерпретации p-Code к JIT). Правда, со всеми присущими динамике ограничениями на пережовываемую сложность. И со сложностью в динамике большие бока — в код для динамики нужно обязательно вставлять счётчики сложности, чтобы суметь вовремя остановиться, т.к. фи-ей оптимизации всё-равно выступает минимальное время выполнения запроса, т.е. эта техника принципиально способна покрыть лишь ничтожное кол-во сценариев. Статика же ничем не ограничена.

И вот я такой читаю самого здешнего мэтра по MS SQL и вижу серьёзный такой косяк, что у него даже на шаг вперёд подумать не получается. Зато пафоса и нервозности хоть отбавляй.


S>Поэтому и не получается конструктивной дискуссии — уж очень разный у вас с Иваном уровень подготовки. Тебе кажется, что он чего-то непонимает

Разумеется.
И не "чего-то", а чудовищный пласт.

Оптимизаторы современных баз давно умеют схлопывать одинаковые запросы с разными константами, более того, они давно умеют НЕ схлопывать запросы в тех случаях, когда планы для разных констант отличаются.

Это у него идёт за аргументы.
Выдавать за аргументы сие можно от полнейшего непонимания происходящего.
Он не мыслит как разработчик СУБД, он мыслит как пользователь, как админ в лучшем случае.
А меня от таких аргументов плющит как от кислого лимона — это насколько надо не понимать происходящее.


S>ровно потому, что он весь ход твоей мысли уже в голове воспроизвёл, получил результаты, прикинул их к реальности, и видит заблуждения, допущенные на самом начальном этапе.

Скажем так, он физически этого сделать не может, потому что не владеет материалом, банально отсутствуют как теоретическое понимание, так и практический опыт по обсуждаемой тематике. Если бы он хотя бы раз написал (пусть небольшую) программу, которая строит дерево перебора вариантов последовательностей выражений РА из исходного РИ (небольшую, потому что кол-во операций РИ пусть будет ограничено), он бы всей этой ереси не писал. И ты бы тоже не писал, сорри. Вы оба плохо представляете процесс перевода РИ в РА, хотя для овладения этим материалом вовсе не надо 32 часа. Особенно человеку с техническим ВО. Я был дал 5-10 часов, этого должно хватить. Дело за желанием.

Здравствуйте, Sinclair, Вы писали:

S>А там, внезапно, в каждом узле хранится много "локальной" информации.

Твоя "локальная информация" имеет строгую иерархическую природу.


S>Например, для пары таблиц, участвующих в Join, там будут храниться конкретные индексы, предикаты, и residuals для этого join.

Смелее, включи воображение.
Ведь ты претендуешь на "разработчика".
Так КАК она будет хранится?


S>И их там как бы дофига, потому что потенциально orders o join manager m on o.managerId = m.id порождает бездну вариантов исполнения.

В указанном виде? ))


S>Грубо говоря, мы можем использовать любой из 5-6 индексов по Manager, потому что а вдруг там в where что-то особенно селективное написано

Прикольный залет, причём, ты уже вроде бы 3-й раз одинаково залетаешь.
Ведь не "вдруг", а на руках полная комбинация всех where.
Эти where часто образуют иерархию, например, where x>100, а потом еще where x>100 and x<1000 и т.д.


S>и любой из 10-15 индексов по order.

За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
Сколько всего таблиц навроде "order" в средней системе?


S>Итого получаем от полусотни до сотни вариантов исполнения этого join.

И это для самой индексированной таблице, аналогов которой единицы штук даже в самых крупных учётных системах.

При том, что про полусотню враки — большая часть вариантов откидываются как заведомо худшие еще на этапе построения всего набора планов.


S>А для вложенных подзапросов там вообще ад и израиль.

Это если плавать в предмете, сорри.
Если на основании предикатов exists, any/all, not in и т.д. — то та же херня что join, вид сбоку, они все через join выразимы.

А если на основании агрегирующих математических ф-ий — то кол-во вариантов планов падает на порядок-другой сразу, бо опять же получается иерархия исполнения всех (сколько бы ни было уровней вложенности) подзапросов.

Я тут рядом как раз разбирал пример с агрегацией+вычислениями:
http://www.rsdn.org/forum/flame.comp/7059865.1


S>Но основная дупа для идеи "компактного представления" ещё и в том, что "внутри" каждого из этих вариантов плана вшиты детали "окружающего" запроса, то есть, если, к примеру, у меня там где-то затесался where ManagerName like @managerNamePrefix+'%', то у меня в аргументах джойна так и будет стоять не index, а результат index scan c соответствующим предикатом.

Пускай стоит.


S>Это означает, что этот вот кусочек плана запроса я не смогу использовать в плане, построенном для другого запроса.

Всё, я сдаюсь.
Коллега, ну это уже упоротость какая-то. ))
План запроса не хранится в виде данных.
Он хранится как код, как ф-ия с параметрами.
Для этого всё и затевалось.
Иерархичность тут проявляется в иерархии вызовов подпрограмм собсно исполнения планов запросов (а не их тупорылой динамической интерпретации, как оно есть сейчас). Итого, вся эта куча подпрограмм вдоль всей иерархии вызова — она многократно повторно используема.

Степень повторного использования можно регулировать через связывания аргументов с константами, т.е. еще на этапе бета-редукции.
При минимальном связывании будет минимальный бинарник, но макимальное кол-во параметров у каждой ф-ии, при максимальном связывании — наоборот.

В классике оптимизации в С++ этим полюсам соответствует оптимизация по размеру бинарника vs оптимизации по эффективности.


S>Шансов на то, что удастся что-то "склеить", т.е. сослаться на один и тот же узел плана запросов несколько раз из разных деревьев, очень мало.

Взял бы ручками да раписал планы вокруг одной и той же комбинации join.
Ты ведь никогда этого не делал, верно?


S>И чем больше размер поддерева, тем больше в нём специфики, и тем меньше шансов на повторное использование.

Я тебя понял.
Улыбнуло.
При исполнении плана дерево тут строго в другую сторону растёт — от примитивных листьев-операций к конкретной сложной операции.
То бишь, каждый лист (в том числе параметрический) принадлежит куче "деревьев"-конкретных планов.


S>Общая экономия будет близка к нулю.

Экономия во-первых не будет нулевой хотя бы потому, что не будет динамики.
Во-вторых, отбросив разницу статики и динамики у нас не будет экономии только тогда, когда каждый индекс каждой таблицы использован только раз в реальных запросах. Не знаю что там говорит твой опыт, но мой говорит строго обратное — индексы вводятся для популярных сценариев доступа к таблице.


S>Так что можно косвенно оценить расходы места под статическую таблицу планов, почитав различные гайды для DBM. Там, где опытные камрады говорят "ну, в принципе 2GB под кэш планов — это немного".

В динамике? Этого даже мало.


S>Причём в кэш попадают исключительно только те планы, которые были реально использованы движком — то есть из наших 50-100 кандидатов на простой join, в кэш попадёт 1.

ИМХО, это может зависеть от конкретной реализации.
Или, например, будет ли это так для параметрического запроса, где выбор конкретного плана зависит от значения параметра?


S>Чтобы хранить прямо все-все-все варианты, нам потребуются сотни гигабайт.

Насос из пальца, однако.
Для сравнения, есть среднейго размера программа на JS, в этой программе куча похожих мест, но все они компилятся движком v8 уникальным образом. После всевозможного джита бинарник в памяти занял порядка 15 метров. Такая же точно программа после нейтивной оптимизации имеет размер сегмента .text порядка 350 KB, т.е. разница примерно в 50 раз.


S>А для тех запросов, где вариантов немного, их и хранить особо незачем — проще построить их на ходу.

Проще чем что?


S>И вот всё это как бы очевидно людям, которые реально занимались оптимизацией реальных SQL запросов как full-time job, а не только единожды сдали 32х часовой курс реляционной алгебры 20 лет назад.

Во-первых, 160 часов минимум. Это для тех, кто не выбрал себе соотв. специализацию.
Кто выбрал, тому еще плюс 60 часов. И да, нет отдельного курса "реляционной алгебры", это всё идёт по технологиям хранения и обработки данных.

И смысл спекулировать часами, если вся вышка идёт порядка 120 часов лекций?
Вообще вся нахрен вышка. ))
Но за 120 часов жизни ты всю вышку не осилишь, верно?
Поэтому её разбивают на аудиторную и самостоятельную работу и потом еще по кучам направлений, некоторые из которых аж на 3-м курсе, что общее кол-во часов переваливает за тысячу.
Понимаешь, к чему я клоню?
Курс РА тоже даётся не сам по себе, а уже на мощной платформе.
Уже до этого была и дискретка, теории множеств, поля/алгебры, компиляторы/интерпретаторы, линейное программирование с минимаксами, теория массового обслуживания и прочее, прочее, прочее.

А так-то да, без понимания происходящего можно было хоть вечно заниматься оптимизацией запросов по принципу научного тыка в чёрный ящик.
Я и сам посвятил несколько лет своей жизни довольно-таки внушительным учётным системам, наелся этого достаточно.
Извини, но про убогость и неповоротливость СУБД образца начала 2000-х знаю не по наслышке.
И что характерно — принципиально мало что поменялось.
Каких-то кучу вещей добавилось (джавы и дотнеты на стороне сервака, кластера и особые режимы репликации и т.д. и т.п.) но в самой базе изменения минимальны до обидного.

Или вот даже коллега IB "удивил" меня тем, что, оказывается, уже лет 10 движки БД умеют распознавать "похожие" некоторые запросы, которые отличаются лишь константой в предикате. И на полном серьёзе думал, что убил этим, даже гнался там за мной и оскорблял. )) При том, что мы как раз обсуждали систему, которая ради именно такой операции и создавалась.

Т.е. должна делать ровно то же самое, но не для "некоторых" запросов, а потенциально для всех.

Чувак даже не потрудился включить голову и сообразить, что раз это МОЖНО делать в статике (я же ему предлагаю именно так делать), то можно попытаться это сделать и в динамике (как перешли от интерпретации p-Code к JIT). Правда, со всеми присущими динамике ограничениями на пережовываемую сложность. И со сложностью в динамике большие бока — в код для динамики нужно обязательно вставлять счётчики сложности, чтобы суметь вовремя остановиться, т.к. фи-ей оптимизации всё-равно выступает минимальное время выполнения запроса, т.е. эта техника принципиально способна покрыть лишь ничтожное кол-во сценариев. Статика же ничем не ограничена.

И вот я такой читаю самого здешнего мэтра по MS SQL и вижу серьёзный такой косяк, что у него даже на шаг вперёд подумать не получается. Зато пафоса и нервозности хоть отбавляй.


S>Поэтому и не получается конструктивной дискуссии — уж очень разный у вас с Иваном уровень подготовки. Тебе кажется, что он чего-то непонимает

Разумеется.
И не "чего-то", а чудовищный пласт.

Оптимизаторы современных баз давно умеют схлопывать одинаковые запросы с разными константами, более того, они давно умеют НЕ схлопывать запросы в тех случаях, когда планы для разных констант отличаются.

Это у него идёт за аргументы.
Выдавать за аргументы сие можно от полнейшего непонимания происходящего.
Он не мыслит как разработчик СУБД, он мыслит как пользователь, как админ в лучшем случае.
А меня от таких аргументов плющит как от кислого лимона — это насколько надо не понимать происходящее.


S>ровно потому, что он весь ход твоей мысли уже в голове воспроизвёл, получил результаты, прикинул их к реальности, и видит заблуждения, допущенные на самом начальном этапе.

Скажем так, он физически этого сделать не может, потому что не владеет материалом, банально отсутствуют как теоретическое понимание, так и практический опыт по обсуждаемой тематике. Если бы он хотя бы раз написал (пусть небольшую) программу, которая строит дерево перебора вариантов последовательностей выражений РА из исходного РИ (небольшую, потому что кол-во операций РИ пусть будет ограничено), он бы всей этой ереси не писал. И ты бы тоже не писал, сорри. Вы оба плохо представляете процесс перевода РИ в РА, хотя для овладения этим материалом вовсе не надо 32 часа. Особенно человеку с техническим ВО. Я был дал 5-10 часов, этого должно хватить. Дело за желанием.