И Oracle, и Microsoft бились за SAP (против DB2), внося изменения в свои базы под лозунгом - лучшая БД для SAP. Именно так прогрес идет у баз данных. Улучшение для 1С не означает, что у остальных начнутся проблемы. 1С генерирует запросы, и там есть определенные закономерности (в том числе - частое использование IN и далее список из тысячи значений - так программист 1С привык писать код), и эти закономерности можно оптимизировать. Почему нет? FreeBSD 10 лет назад оптимизировалось под Postgres, чтобы ускорить свою систему работы с памятью и файловой системой
Имейте в виду, что если вы написали unique1 IN (0,1), то это просто эквивалент unique1=0 OR unique1=1 - обычное выражение. А если добавили VALUES, то у вас скобки возвращают подзапрос со всей вытекающей обработкой подзапроса. И в документации IN описан в двух местах, как два оператора. VALUES - это эквиваент SELECT 0 union SELECT 1 - фактически обрезанная форма команды SELECT без FROM.
Наоборот, начиная с С++11 наконец на С++ стало писать проще, благодаря новым функциям языка и новым шаблонам разработки. И проявился такой неожиданный эффект - код на новых стандартах просто работает на всех системах, где этот стандарт поддерживается - фактически - везде. С++ повезло, что у него есть Бьёрн с его энергией и авторитетом.
Я из статьи понял, что измерялось и первое - точное совпадение, и второе - достаточно правильного результата. Учитывая, что речь идет о замене аналитика (как вы написали), то пользователь (у которого до этого и не было никогда аналитика) делает запрос, ждет результат, не дожидается за то время, за которое хотел его получить, жмет кнопку прервать, переформулирует вопрос. В его ситуации альтернатива - вообще не делать запросы, так как SQL надо учить, а далеко не все программисты. Это может быть директор компании или собственник бизнеса, у него своих проблем в жизни хватает
Это же бенчмарк, на котором такие модели проверяются. Обычно всегда такие работы ссылаются на то, как они выполнили бенчмарк Spider. Его давно сделали, и эта статья не про бенчмарк, и не про запросы в нем. И вроде бы автор не писал, что модель тренировалась на запросах из бенчмарка. То есть, к формулам в статье вопросов нет, все понятно, но непонятно, с какой стороны смотреть на запросы.
В mssql сервере indexed views реализованы через триггеры (которые не высвечиваются в списке триггеров) и, конечно, как вы написали, такое дорого поддерживать на триггерах. Кроме того, indexed views имеют ограничения по запросам на FULL и LEFT join, на использование столбцов - запросы надо переписывать.
Позвольте осторожно Вас поправить - SQL server - это официальное название этого продукта Microsoft. Под таким названием он проходит в документации и, например, настройках драйверов, где указывается тип подключаемой базы. MS в названии нет.
PostgreSQL ранее назывался Postgres, но после переименования в PostgreSQL (Postgres Query Language) начались разные толкования этого имени (как Postgre SQL, postgre), после чего автор переименования назвал это одной из своих больших ошибок в жизни. SQL - это только название. Постгрес - это сервер баз данных, а не SQL сервер. SQL у него - крошечное мгновение перед функцией Parse()
У меня к SQLServer вопросов нет (есть у них INCLUDE или нет). Что такого не делает индекс btree PostgreSQL c INCLUDE, что делает кластерный индекс SQLServer? Я бы сказал, что при прочих равных у SQLServer есть оверхед из-за того, что он вынуждает для этой таблицы использовать не указатель строки, а ключ индексирования, что может быть длиннее указателя строки. Дополнительный минус при прочих равных - SQLServer хранит все столбцы (так надо, тут вопросов нет), но и поиск по дереву из-за этого требует большего ввода-вывода. Зато есть слово CLUSTER, а у другие его используют для других целей.
В Постгрес добавлено ключевое слово INCLUDE в создание индекса, которое выполняет ровно те же функции, что и кластерный индекс SQLServer, только с дополнительной гибкостью по выбору полей и по использованию в других видах индексов, а не только BTREE. Но мы упорно не будет это замечать, так как там нет слова CLUSTER.
Ссылки на превосходство «эталона» ничем не обоснованы, так как бенчмарки с участием Оракла без письменного разрешения Оракла законодательно запрещены. Все крупнейшие базы реализованы на различных вариантах mvcc, бенчмарки показывают, что реализация в целом неплохая и конкурентоспособная. Сейчас статьи нет под рукой, но поищу и приложу ссылки на статьи с бенчмарками версионного контроля в базах.
ответить на ваш вопрос очень просто (и ссылка на ответ есть как раз в ClickBench, о котором статья) - если вы опубликуете такой бенчмарк про Оракл или MSSQL, готовьтесь быть арестованным в ближайшем аэропорту свободного мира - https://cube.dev/blog/dewitt-clause-or-can-you-benchmark-a-database . Но у этого есть плюс - если видите в бенчмарках любое упоминание этих неприкасаемых, сразу ясно, кто за него платит за этот бенчмарк, и почему все остальные такие плохие.
не надо так строго критиковать этот бенчмарк, это как ребенка обижать 😀, рука не поднимается. В нем некоторые базы сами по умолчанию строят индексы в больших количествах, поскольку такой формат таблицы. Зато на вопрос - что со скоростью записи ? - ответ будет - какой записи? Это аппенд-онли таблица, причем на один раз. Метаданные, индексы - все в конце таблицы, дописать - это создать новую такую же плюс новые данные. Зато мы ее из S3 можем считать, по сети. Такое видение OLAP сегодня у некоторых.
тут победить мог кто угодно, так как одним сказали скакать вон той короткой дорогой (используя индексы), а другим вон той длинной песчаной (без единого индекса) и с грузом (fillfactor у таблицы 70% для ускорения записи, а тестировалось только чтение). Этот бенчмарк изначально делался, чтобы оценить скорость нескольких систем, чтобы сделать выбор для конкретной ситуации.
Про парсер - я имею в виду, что парсер создал для VALUES двумерный массив выражений (строка-столбец). Эти выражения могут давать константный результат, то это не известно - для этого надо вычислить значения этих элементов. На этапе парсера и на этапе начала планирования нельзя сказать, из константных элементов состоит VALUES или там есть переменные. А когда уже можно сказать, то уже поздно что-то менять. Интересно, а mssql как делает планирование таких VALUES. У меня под рукой его нет.
А куда ему родному деваться-то? Так реляционная алгебра постулирует.
Тут даже более приземленно - для планировщика это одно из отношений (с типом VALUES) и он ничего не знает о его содержимом, так как его окончательное содержимое выдаст экзекьютор, выполнив этот узел.
Пока parser отдельно не выделяет константные VALUES (без условий, сортировок и LIMIT), планировщик ничего не сможет сделать
И Oracle, и Microsoft бились за SAP (против DB2), внося изменения в свои базы под лозунгом - лучшая БД для SAP. Именно так прогрес идет у баз данных. Улучшение для 1С не означает, что у остальных начнутся проблемы. 1С генерирует запросы, и там есть определенные закономерности (в том числе - частое использование IN и далее список из тысячи значений - так программист 1С привык писать код), и эти закономерности можно оптимизировать. Почему нет? FreeBSD 10 лет назад оптимизировалось под Postgres, чтобы ускорить свою систему работы с памятью и файловой системой
Имейте в виду, что если вы написали unique1 IN (0,1), то это просто эквивалент unique1=0 OR unique1=1 - обычное выражение. А если добавили VALUES, то у вас скобки возвращают подзапрос со всей вытекающей обработкой подзапроса. И в документации IN описан в двух местах, как два оператора. VALUES - это эквиваент SELECT 0 union SELECT 1 - фактически обрезанная форма команды SELECT без FROM.
Наоборот, начиная с С++11 наконец на С++ стало писать проще, благодаря новым функциям языка и новым шаблонам разработки. И проявился такой неожиданный эффект - код на новых стандартах просто работает на всех системах, где этот стандарт поддерживается - фактически - везде. С++ повезло, что у него есть Бьёрн с его энергией и авторитетом.
Спасибо за статью!
А вы не могли бы пояснить, почему из всего списка чатов вы на первое место поставили именно ChatGPT, который не предоставляет сервис для России?
Я из статьи понял, что измерялось и первое - точное совпадение, и второе - достаточно правильного результата. Учитывая, что речь идет о замене аналитика (как вы написали), то пользователь (у которого до этого и не было никогда аналитика) делает запрос, ждет результат, не дожидается за то время, за которое хотел его получить, жмет кнопку прервать, переформулирует вопрос. В его ситуации альтернатива - вообще не делать запросы, так как SQL надо учить, а далеко не все программисты. Это может быть директор компании или собственник бизнеса, у него своих проблем в жизни хватает
Это же бенчмарк, на котором такие модели проверяются. Обычно всегда такие работы ссылаются на то, как они выполнили бенчмарк Spider. Его давно сделали, и эта статья не про бенчмарк, и не про запросы в нем. И вроде бы автор не писал, что модель тренировалась на запросах из бенчмарка. То есть, к формулам в статье вопросов нет, все понятно, но непонятно, с какой стороны смотреть на запросы.
Скажите, а может быть такая ситуация, что в процессе кодирования 8K страницы результат будет более 8K?
В mssql сервере indexed views реализованы через триггеры (которые не высвечиваются в списке триггеров) и, конечно, как вы написали, такое дорого поддерживать на триггерах. Кроме того, indexed views имеют ограничения по запросам на FULL и LEFT join, на использование столбцов - запросы надо переписывать.
Позвольте осторожно Вас поправить - SQL server - это официальное название этого продукта Microsoft. Под таким названием он проходит в документации и, например, настройках драйверов, где указывается тип подключаемой базы. MS в названии нет.
PostgreSQL ранее назывался Postgres, но после переименования в PostgreSQL (Postgres Query Language) начались разные толкования этого имени (как Postgre SQL, postgre), после чего автор переименования назвал это одной из своих больших ошибок в жизни. SQL - это только название. Постгрес - это сервер баз данных, а не SQL сервер. SQL у него - крошечное мгновение перед функцией Parse()
У меня к SQLServer вопросов нет (есть у них INCLUDE или нет). Что такого не делает индекс btree PostgreSQL c INCLUDE, что делает кластерный индекс SQLServer? Я бы сказал, что при прочих равных у SQLServer есть оверхед из-за того, что он вынуждает для этой таблицы использовать не указатель строки, а ключ индексирования, что может быть длиннее указателя строки. Дополнительный минус при прочих равных - SQLServer хранит все столбцы (так надо, тут вопросов нет), но и поиск по дереву из-за этого требует большего ввода-вывода. Зато есть слово CLUSTER, а у другие его используют для других целей.
В Постгрес добавлено ключевое слово INCLUDE в создание индекса, которое выполняет ровно те же функции, что и кластерный индекс SQLServer, только с дополнительной гибкостью по выбору полей и по использованию в других видах индексов, а не только BTREE. Но мы упорно не будет это замечать, так как там нет слова CLUSTER.
Ссылки на превосходство «эталона» ничем не обоснованы, так как бенчмарки с участием Оракла без письменного разрешения Оракла законодательно запрещены. Все крупнейшие базы реализованы на различных вариантах mvcc, бенчмарки показывают, что реализация в целом неплохая и конкурентоспособная. Сейчас статьи нет под рукой, но поищу и приложу ссылки на статьи с бенчмарками версионного контроля в базах.
ответить на ваш вопрос очень просто (и ссылка на ответ есть как раз в ClickBench, о котором статья) - если вы опубликуете такой бенчмарк про Оракл или MSSQL, готовьтесь быть арестованным в ближайшем аэропорту свободного мира - https://cube.dev/blog/dewitt-clause-or-can-you-benchmark-a-database . Но у этого есть плюс - если видите в бенчмарках любое упоминание этих неприкасаемых, сразу ясно, кто за него платит за этот бенчмарк, и почему все остальные такие плохие.
Кстати, да, почему-то с этим колоночными типами бенчмарка нет. тут хотя бы сопоставимая среда сравнивалась - Postgres с колонками и без
не надо так строго критиковать этот бенчмарк, это как ребенка обижать 😀, рука не поднимается. В нем некоторые базы сами по умолчанию строят индексы в больших количествах, поскольку такой формат таблицы. Зато на вопрос - что со скоростью записи ? - ответ будет - какой записи? Это аппенд-онли таблица, причем на один раз. Метаданные, индексы - все в конце таблицы, дописать - это создать новую такую же плюс новые данные. Зато мы ее из S3 можем считать, по сети. Такое видение OLAP сегодня у некоторых.
тут победить мог кто угодно, так как одним сказали скакать вон той короткой дорогой (используя индексы), а другим вон той длинной песчаной (без единого индекса) и с грузом (fillfactor у таблицы 70% для ускорения записи, а тестировалось только чтение). Этот бенчмарк изначально делался, чтобы оценить скорость нескольких систем, чтобы сделать выбор для конкретной ситуации.
А вот, кстати, и вариант для тестирования https://sqlize.online/sql/mssql2017/2fed3c7e1c23a573e04630837f8f82a8/
Про парсер - я имею в виду, что парсер создал для VALUES двумерный массив выражений (строка-столбец). Эти выражения могут давать константный результат, то это не известно - для этого надо вычислить значения этих элементов. На этапе парсера и на этапе начала планирования нельзя сказать, из константных элементов состоит VALUES или там есть переменные. А когда уже можно сказать, то уже поздно что-то менять. Интересно, а mssql как делает планирование таких VALUES. У меня под рукой его нет.
Тут даже более приземленно - для планировщика это одно из отношений (с типом VALUES) и он ничего не знает о его содержимом, так как его окончательное содержимое выдаст экзекьютор, выполнив этот узел.
Пока parser отдельно не выделяет константные VALUES (без условий, сортировок и LIMIT), планировщик ничего не сможет сделать