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

V>>Твоя "локальная информация" имеет строгую иерархическую природу.
S>(facepalm)/
V>>Так КАК она будет хранится?
S>Это как раз неважно.

Тогда зачем ты сюда пишешь если не разобрался?
Тебе самому скучно и ты решил сделать скучно другим?


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

Типа, лучшая оборона — это нападение?


V>>Ведь не "вдруг", а на руках полная комбинация всех where.
S>Это в конкретном запросе. С конкретными значениями параметров.

Пофик. Речь шла о полном наборе планов.
Т.е. твои возражения НЕ релевантны обсуждаемому и являются, по-сути, подлогом/жульничеством.
А выдаваемые таким тоном если, то это еще и показуха получается, работа на публику.
Ну или ты действительно ни черта не понимаешь.


V>>Эти where часто образуют иерархию, например, where x>100, а потом еще where x>100 and x<1000 и т.д.
S>Вот это место не имеет физического смысла. Даже если у нас есть много предикатов на один и тот же атрибут, то никакой иерархии они не образуют.

Мде...
Например, движок оптимизации того же MySQL использует библиотеки Буста Graph и Geometry.
И если насчёт graph понятно, как ты думаешь, зачем там geometry? Что именно используется?


V>>За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
S>Твои представления о том, за что положено расстреливать, а за что — увольнять, выдают малый опыт в обсуждаемой теме.

Ты сказал конкретно order, вот и отвечай за order.
А натягивать "почти OLAP" я же первый не рекомендовал сразу же, бо там ДРУГОЙ сценарий.

Я сразу же оговорился, что для оперативных и исторических данных используют РАЗНЫЕ подходы.
Исторические данные неизменны.
Оперативные — наоборот.
Смешивать их и при этом заявлять о своём "опыте" — это нагло врать.
Врать или о своём опыте или о своей претензии на честность дискуссии.

Ну реально, ты такой бежишь размахивать 15-ю индексами.
Это для частоизменяемых данных? ))
ОМГ...
Уволить. Расстрелять.
Это не инженерия, это вредительство.
"Куда вы все лезете, там Ад и Израиль!!!"
Мол, "я же не лезу, вот и вы не лезьте".


V>>Сколько всего таблиц навроде "order" в средней системе?
S>Смотря что считать "средней системой".

В средней современной системе в р-не 800-1000 таблиц.
Но ты опять пустословишь вместо разговора по-существу, заметь.


S>>>Итого получаем от полусотни до сотни вариантов исполнения этого join.
V>>И это для самой индексированной таблице, аналогов которой единицы штук даже в самых крупных учётных системах.
S>Это мы говорим про 1 джойн. В самой средней учётной системе мы регулярно имеем запросы с 5-10 джойнами.

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

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

Ну наёдешь ты какой-нить уникальный ЖУТКО РЕДКИЙ сценарий, который не ляжет гладко на предполагаемую систему.
Ну и на здоровье, возьми более подходящий для такой уникальной задачи инструмент, какие проблемы?
Ты инженер или где, что ты ерунду-то детсадовскую уже который пост подряд пишешь? )))


S>Потому как схемы высоконормализованные

Для высоконормализованных схем не будет такой ширины таблицы, чтобы по 15 индексов лепить.


S>И как раз обычно в них ровно одна такая "самая индексированная" таблица.

Видели, знаем, выжигали калёным железом.
Это тот самый широко известный в узких кругах OLAP для бедных.
Кароч, откройте для себя репликацию и OLAP для взрослых.
Стоило один раз показать и взрослые люди радовались как малые дети.

Самые существенные изменения в БД за последние лет 20 — они как раз в плане репликаций.
Их появилось столько режимов и столько инструментов под них — у-у-у.
Но, судя по 15-ти индексам, это всё каким-то чудесным образом тебя не коснулось.

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

Так вот, в чём суть твоего мухлежа:
— для оперативных данных много индексов не надо, их обычно ровно 3 во всех перечисленных типах систем (для упомянутой основной таблицы движений);
— для исторических данных не надо много динамических планов, бо данные неизменяемые, индексы априори пересчитаны, как я предлагал т.н. "профилирование по реальным данным" — оно вполне может быть частью операции "закрытие периода" — это одна из самых важных операций ЛЮБЫХ учётных систем более-менее серьезного уровня.


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

Да бывает такая хрень в алгоритмах Uniform Cost Search или Topological Sort.
Смирись. ))


S>Для каждого из них бывает такая комбинация параметров запроса и набора данных в таблице, когда именно этот вариант плана выиграет.

Бывает. Но это должен быть запрос соответствующий. А все запросы заранее известны. А таких специфических запросов и 1% не будет.
И про размен явной параметризации на эффективность я тебе уже говорил.
Вполне можно настраивать пороги, когда мы еще можем позволить себе генерить код вширь (распространение подстановок), а когда уже хватит.

Похоже, ты не понимаешь, как такие вещи работают.
Сначала происходит "распознавание" похожих мест — т.е. из вообще всех таблиц и всех запросов.
Если интересует конкретно — спроси меня как.
Я когда-то писал часть системы по распознаванию смысла текстов.
Тоже относительно несложные алгоритмы на графах и подобиях.
Семантику языков программирования (даже 4-го уровня) "распознавать" еще проще.
Не синтаксис, а именно семантику — т.е. "что конкретно ты имел ввиду".
Т.е. по набору примитивных операций выходить на более высокий "смысл" происходящего.
И здесь уже производить преобразования подобия.


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

Ну т.е. понимаешь, что пример был не в кассу после обсуждения join?


V>>А если на основании агрегирующих математических ф-ий — то кол-во вариантов планов падает на порядок-другой сразу, бо опять же получается иерархия исполнения всех (сколько бы ни было уровней вложенности) подзапросов.
S>Возрастает. На порядок возрастает. Потому что возникают варианты "сначала join, потом агрегация", либо "агрегация, потом join".

Вот, опять нечестная манипуляция.
Я верю что ты не понимаешь, что это зависит от конкретного запроса, т.е. где конкретно происходит агрегация и по чему именно происходит join.
Т.е. "возрастает" там только в смысле мощности порождаемых языком комбинаций, но никак не в смысле множества вариантов исполнения конкретного такого выражения. Потому для каждого конкретного выражения — многократно падает. Сама операция агрегации отрезает нахрен кучу потенциальных планов, которые имели право на жизнь в отсутствии такой агрегации. Потому что дело не в том "сначала агрегация, потом join", а в том — какие таблицы сначала сканить, именно такой выбор сужается многократно.


V>>Всё, я сдаюсь.
V>>Коллега, ну это уже упоротость какая-то. ))
S>Нет, это близкое знакомство с предметом.

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


V>>План запроса не хранится в виде данных.
V>>Он хранится как код, как ф-ия с параметрами.
V>>Для этого всё и затевалось.
S>Очень хорошо.


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

Важно.


S>SQL-сервер хранит это в виде дерева физических операций, при исполнении — интерпретирует.

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



S>Ок, мы можем "улучшить" ситуацию путём генерации не объектов-описаний, а, к примеру, Expression<>. Или байткода в стиле MSIL, LLVM, или Java.

Дык, дотнет и джаву ругают как раз за то, что они принципиально не в состоянии производить описанные оптимизации.
Поэтому, их бинарник в памяти после джита занимает какое-то совсем уж неприличное кол-во байт, что джаве даже пришлось ввести сборку мусора для кода, ы-ы-ы (привет из 90-х, когда память стоила дороже золота).

Зато .Net Native — запросто может.
Стирание типов — великая весчь.


S>Или сразу вообще скомпилировать бинарь. Это повлияет только на скорость исполнения этого плана. На место, которое он занимает, это повлияет в плохую сторону.

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

А сравнение со сриптовым языком после джита я тебе уже приводил — разница до 50-ти раз.
А кеш проца ведь не бесконечный. Чем реже оттуда вытесняется код, тем эффективнее вся система.


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

Верно. Он ведь может вообще все планы дать.
Так сколько он в среднем даёт планов по одному join?

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

Давай мы сделаем паузу, пока ты не поймешь этот момент.
Потому что иначе выходит что мы обсуждаем разные предполагаемые системы.

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

V>>Твоя "локальная информация" имеет строгую иерархическую природу.
S>(facepalm)/
V>>Так КАК она будет хранится?
S>Это как раз неважно.

Тогда зачем ты сюда пишешь если не разобрался?
Тебе самому скучно и ты решил сделать скучно другим?


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

Типа, лучшая оборона — это нападение?


V>>Ведь не "вдруг", а на руках полная комбинация всех where.
S>Это в конкретном запросе. С конкретными значениями параметров.

Пофик. Речь шла о полном наборе планов.
Т.е. твои возражения НЕ релевантны обсуждаемому и являются, по-сути, подлогом/жульничеством.
А выдаваемые таким тоном если, то это еще и показуха получается, работа на публику.
Ну или ты действительно ни черта не понимаешь.


V>>Эти where часто образуют иерархию, например, where x>100, а потом еще where x>100 and x<1000 и т.д.
S>Вот это место не имеет физического смысла. Даже если у нас есть много предикатов на один и тот же атрибут, то никакой иерархии они не образуют.

Мде...
Например, движок оптимизации того же MySQL использует библиотеки Буста Graph и Geometry.
И если насчёт graph понятно, как ты думаешь, зачем там geometry? Что именно используется?


V>>За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
S>Твои представления о том, за что положено расстреливать, а за что — увольнять, выдают малый опыт в обсуждаемой теме.

Ты сказал конкретно order, вот и отвечай за order.
А натягивать "почти OLAP" я же первый не рекомендовал сразу же, бо там ДРУГОЙ сценарий.

Я сразу же оговорился, что для оперативных и исторических данных используют РАЗНЫЕ подходы.
Исторические данные неизменны.
Оперативные — наоборот.
Смешивать их и при этом заявлять о своём "опыте" — это нагло врать.
Врать или о своём опыте или о своей претензии на честность дискуссии.

Ну реально, ты такой бежишь размахивать 15-ю индексами.
Это для частоизменяемых данных? ))
ОМГ...
Уволить. Расстрелять.
Это не инженерия, это вредительство.
"Куда вы все лезете, там Ад и Израиль!!!"
Мол, "я же не лезу, вот и вы не лезьте".


V>>Сколько всего таблиц навроде "order" в средней системе?
S>Смотря что считать "средней системой".

В средней современной системе в р-не 800-1000 таблиц.
Но ты опять пустословишь вместо разговора по-существу, заметь.


S>>>Итого получаем от полусотни до сотни вариантов исполнения этого join.
V>>И это для самой индексированной таблице, аналогов которой единицы штук даже в самых крупных учётных системах.
S>Это мы говорим про 1 джойн. В самой средней учётной системе мы регулярно имеем запросы с 5-10 джойнами.

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

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

Ну найдешь ты какой-нить уникальный ЖУТКО РЕДКИЙ сценарий, который не ляжет гладко на предполагаемую систему.
Ну и на здоровье, возьми более подходящий для такой уникальной задачи инструмент, какие проблемы?
Ты инженер или где? )))


S>Потому как схемы высоконормализованные

Для высоконормализованных схем не будет такой ширины таблицы, чтобы по 15 индексов лепить.


S>И как раз обычно в них ровно одна такая "самая индексированная" таблица.

Видели, знаем, выжигали калёным железом.
Это тот самый широко известный в узких кругах OLAP для бедных.
Кароч, откройте для себя репликацию и OLAP для взрослых.
Стоило один раз показать и взрослые люди радовались как малые дети.

Самые существенные изменения в БД за последние лет 20 — они как раз в плане репликаций.
Их появилось столько режимов и столько инструментов под них — у-у-у.
Но, судя по 15-ти индексам, это всё каким-то чудесным образом тебя не коснулось.

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

Так вот, в чём суть твоего мухлежа:
— для оперативных данных много индексов не надо, их обычно ровно 3 во всех перечисленных типах систем (для упомянутой основной таблицы движений);
— для исторических данных не надо много динамических планов, бо данные неизменяемые, индексы априори пересчитаны, как я предлагал т.н. "профилирование по реальным данным" — оно вполне может быть частью операции "закрытие периода" — это одна из самых важных операций ЛЮБЫХ учётных систем более-менее серьезного уровня.


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

Да бывает такая хрень в алгоритмах Uniform Cost Search или Topological Sort.
Смирись. ))


S>Для каждого из них бывает такая комбинация параметров запроса и набора данных в таблице, когда именно этот вариант плана выиграет.

Бывает. Но это должен быть запрос соответствующий. А все запросы заранее известны. А таких специфических запросов и 1% не будет.
И про размен явной параметризации на эффективность я тебе уже говорил.
Вполне можно настраивать пороги, когда мы еще можем позволить себе генерить код вширь (распространение подстановок), а когда уже хватит.

Похоже, ты не понимаешь, как такие вещи работают.
Сначала происходит "распознавание" похожих мест — т.е. из вообще всех таблиц и всех запросов.
Если интересует конкретно — спроси меня как.
Я когда-то писал часть системы по распознаванию смысла текстов.
Тоже относительно несложные алгоритмы на графах и подобиях.
Семантику языков программирования (даже 4-го уровня) "распознавать" еще проще.
Не синтаксис, а именно семантику — т.е. "что конкретно ты имел ввиду".
Т.е. по набору примитивных операций выходить на более высокий "смысл" происходящего.
И здесь уже производить преобразования подобия.


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

Ну т.е. понимаешь, что пример был не в кассу после обсуждения join?


V>>А если на основании агрегирующих математических ф-ий — то кол-во вариантов планов падает на порядок-другой сразу, бо опять же получается иерархия исполнения всех (сколько бы ни было уровней вложенности) подзапросов.
S>Возрастает. На порядок возрастает. Потому что возникают варианты "сначала join, потом агрегация", либо "агрегация, потом join".

Вот, опять нечестная манипуляция.
Я верю что ты не понимаешь, что это зависит от конкретного запроса, т.е. где конкретно происходит агрегация и по чему именно происходит join.
Т.е. "возрастает" там только в смысле мощности порождаемых языком комбинаций, но никак не в смысле множества вариантов исполнения конкретного такого выражения. Потому для каждого конкретного выражения — многократно падает. Сама операция агрегации отрезает нахрен кучу потенциальных планов, которые имели право на жизнь в отсутствии такой агрегации. Потому что дело не в том "сначала агрегация, потом join", а в том — какие таблицы сначала сканить, именно такой выбор сужается многократно.


V>>Всё, я сдаюсь.
V>>Коллега, ну это уже упоротость какая-то. ))
S>Нет, это близкое знакомство с предметом.

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


V>>План запроса не хранится в виде данных.
V>>Он хранится как код, как ф-ия с параметрами.
V>>Для этого всё и затевалось.
S>Очень хорошо.


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

Важно.


S>SQL-сервер хранит это в виде дерева физических операций, при исполнении — интерпретирует.

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



S>Ок, мы можем "улучшить" ситуацию путём генерации не объектов-описаний, а, к примеру, Expression<>. Или байткода в стиле MSIL, LLVM, или Java.

Дык, дотнет и джаву ругают как раз за то, что они принципиально не в состоянии производить описанные оптимизации.
Поэтому, их бинарник в памяти после джита занимает какое-то совсем уж неприличное кол-во байт, что джаве даже пришлось ввести сборку мусора для кода, ы-ы-ы (привет из 90-х, когда память стоила дороже золота).

Зато .Net Native — запросто может.
Стирание типов — великая весчь.


S>Или сразу вообще скомпилировать бинарь. Это повлияет только на скорость исполнения этого плана. На место, которое он занимает, это повлияет в плохую сторону.

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

А сравнение со сриптовым языком после джита я тебе уже приводил — разница до 50-ти раз.
А кеш проца ведь не бесконечный. Чем реже оттуда вытесняется код, тем эффективнее вся система.


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

Верно. Он ведь может вообще все планы дать.
Так сколько он в среднем даёт планов по одному join?

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

Давай мы сделаем паузу, пока ты не поймешь этот момент.
Потому что иначе выходит что мы обсуждаем разные предполагаемые системы.