Здравствуйте, gandjustas, Вы писали:
G>>>По MySQL все описано тут https://dev.mysql.com/doc/refman/8.0/en/optimization.html
… S>>Вообще, похоже, за три мажорных релиза, прошедших с тех пор, как я на него смотрел в последний раз, ребята неплохо продвинулись G>Есть такое, но доверия пока мало. Опыт знакомых говорит что MySQL все еще нещадно тормозит на нетривиальных запросах.
_FR>Оу, спасибо, смотрю они придумали воркэраунд (через CTE) для невозможности селф-джойна временной таблицы.
Ну так это же не временная таблица. Это не воркэраунд, это смена семантики запроса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Gt_>здравый смысл ? и это про базу которая три десятилетия фигачила десяток типов блокировок которые так и ничего кроме дедлоков и не дали, все равно как у оракла и пострес версионность пришлось прикручивать ?
не там проблемы ищешь. с кривыми руками и соответственно архитектурой приложения можно положить что угодно.
Здравствуйте, nikkit, Вы писали:
n> Gt_>здравый смысл ? и это про базу которая три десятилетия фигачила десяток типов блокировок которые так и ничего кроме дедлоков и не дали, все равно как у оракла и пострес версионность пришлось прикручивать ? n> не там проблемы ищешь. с кривыми руками и соответственно архитектурой приложения можно положить что угодно.
Например, такое принципиально не лечится. Блокировочникам место в анналах истории.
Gt_>>здравый смысл ? и это про базу которая три десятилетия фигачила десяток типов блокировок которые так и ничего кроме дедлоков и не дали, все равно как у оракла и пострес версионность пришлось прикручивать ?
N>не там проблемы ищешь. с кривыми руками и соответственно архитектурой приложения можно положить что угодно.
можно положить что у годно, но это можно же было изначально положиться на здравый смысл и сделать нормально, у нас перед глазами оракл и постгрес. а у мсскл вышло порно которое пытались лечить всякими хинтами в стиле skip locked, блокировками намерений и прочей наркоманией. теперь в базе может быть пол транзакций блокировочные, другая на snapshot. и глядя на это ты нам втираешь про здравый смысл и интуицию ? да у мсскл основные счетчики спрятаны в performance мониторе винды, команды shirnk не отрабатывают по десятку причин, кластер, который и близко не кластер. не стоит втирать про здравый смысл с таким поделием.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AndrewN, Вы писали: AN>>То, что в MSSQL TOP 1 имеет более высокий приоритет над DISTINCT — вот это реальный трэш. S>Хотелось бы увидеть пример таблицы, для которой такой приоритет операций приведёт к неверному результату.
стоит заменить (1) на что-то другое и поле примеров заметно расширится
S>"Реальный трэш" — это когда запрос выдаёт не то, что должен. S>"Просто трэш" — это когда оптимизатор не использует какую-нибудь очевидную эквивалентность и перемалывает байты впустую. S>А когда оптимизатор выбирает оптимальный способ исполнения запроса, гарантируя сохранение семантики — это как раз норма.
что, в оптимизаторе написан специальный кейс для top 1?
Здравствуйте, Константин Л., Вы писали:
КЛ>стоит заменить (1) на что-то другое и поле примеров заметно расширится
А, понятно. Ну, это просто непонимание семантики SQL. Приоритет операций надо задавать вложенными запросами.
select distinct * from (select top 10 ...);
S>>"Реальный трэш" — это когда запрос выдаёт не то, что должен. S>>"Просто трэш" — это когда оптимизатор не использует какую-нибудь очевидную эквивалентность и перемалывает байты впустую. S>>А когда оптимизатор выбирает оптимальный способ исполнения запроса, гарантируя сохранение семантики — это как раз норма.
КЛ>что, в оптимизаторе написан специальный кейс для top 1?
В хорошем — должен быть. Потому что разные алгоритмы джойна имеют разные оценки для времени получения первой записи и для времени получения последней записи.
Если у нас нет top, то надо выбирать алгоритм, который долго запрягает, но быстро ездит.
А если есть — то наоборот, надо выбирать алгоритм, который быстро выдаст начало. Даже если он в целом будет медленнее — неважно, ведь работа всё равно будет прервана после отдачи первых N записей.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Dym On, Вы писали:
N>>просто в отличие от sql server, на оракле и постгресс здравый смысл и интуицию использовать бесполезно. нужно обязательно читать мануалы DO>Мануалы нужно вообще читать, и лучше перед тем, как что-то собираешься сделать.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Константин Л., Вы писали:
КЛ>>стоит заменить (1) на что-то другое и поле примеров заметно расширится S>А, понятно. Ну, это просто непонимание семантики SQL. Приоритет операций надо задавать вложенными запросами. S>
S>select distinct * from (select top 10 ...);
S>
разность двух интуиций
КЛ>>что, в оптимизаторе написан специальный кейс для top 1? S>В хорошем — должен быть. Потому что разные алгоритмы джойна имеют разные оценки для времени получения первой записи и для времени получения последней записи. S>Если у нас нет top, то надо выбирать алгоритм, который долго запрягает, но быстро ездит. S>А если есть — то наоборот, надо выбирать алгоритм, который быстро выдаст начало. Даже если он в целом будет медленнее — неважно, ведь работа всё равно будет прервана после отдачи первых N записей.
Gt_>можно положить что у годно, но это можно же было изначально положиться на здравый смысл и сделать нормально, у нас перед глазами оракл и постгрес. а у мсскл вышло порно которое пытались лечить всякими хинтами в стиле skip locked, блокировками намерений и прочей наркоманией. теперь в базе может быть пол транзакций блокировочные, другая на snapshot. и глядя на это ты нам втираешь про здравый смысл и интуицию ? да у мсскл основные счетчики спрятаны в performance мониторе винды, команды shirnk не отрабатывают по десятку причин, кластер, который и близко не кластер. не стоит втирать про здравый смысл с таким поделием.
в запросах писать with(nolock) религия не позволяет?
Gt_>>можно положить что у годно, но это можно же было изначально положиться на здравый смысл и сделать нормально, у нас перед глазами оракл и постгрес. а у мсскл вышло порно которое пытались лечить всякими хинтами в стиле skip locked, блокировками намерений и прочей наркоманией. теперь в базе может быть пол транзакций блокировочные, другая на snapshot. и глядя на это ты нам втираешь про здравый смысл и интуицию ? да у мсскл основные счетчики спрятаны в performance мониторе винды, команды shirnk не отрабатывают по десятку причин, кластер, который и близко не кластер. не стоит втирать про здравый смысл с таким поделием.
N>в запросах писать with(nolock) религия не позволяет?
если цель показать на сколько далек мсскл от логики — да, можно и грязное чтение.
Здравствуйте, Константин Л., Вы писали:
КЛ>разность двух интуиций
КЛ>>>что, в оптимизаторе написан специальный кейс для top 1? S>>В хорошем — должен быть. Потому что разные алгоритмы джойна имеют разные оценки для времени получения первой записи и для времени получения последней записи. S>>Если у нас нет top, то надо выбирать алгоритм, который долго запрягает, но быстро ездит. S>>А если есть — то наоборот, надо выбирать алгоритм, который быстро выдаст начало. Даже если он в целом будет медленнее — неважно, ведь работа всё равно будет прервана после отдачи первых N записей.
КЛ>не для top n, для top 1
Ну вообще можно и для top 1, не убудет.
top 1 (ну в смысле limit 1) это довольно частый вариант, его оптимизация стоит того.
Оптимизатор в Постгресе говно, как ни крути.
Он потихоньку становится лучше. Но говна там все еще навалом.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, nikkit, Вы писали:
N>>ну как так-то? и нахрена так было сделано? может есть разумное объяснение такому поведению? M>DISTINCT это автоматом GROUP BY, что тормознее даже, чем ORDER BY
Нет не тормознее. Там банальный Hash Aggregate, т.е. запихивание значений в HashSet, что гораздо проще сортировки.
Здравствуйте, gandjustas, Вы писали:
G>На самом деле для человека, владеющего техниками оптимизации для SQL Server изучить оптимизацию для Postgres несложно, там примерно на порядок меньше вариантов операторов в плане, а множество типов индексов, которых нет в SQL Server, оптимизируют вполне конкретные функции. G>Остается только разобраться с vacuum.
На порядок, это сколько, в сравнении? Я просто немного с mssql знаком (с postgres знаком очень хорошо), а вы похоже наоборот.
Но я там не заметил на порядок большего количества типов шагов. в плане выполнения (про это я так понимаю речь?). А количество индексов в Постгресе не просто так, они для специфических типов данных (массивов, деревьев, geo координат и т.п.), которые отдельно в mssql не поддерживаются.
Здравствуйте, VladiCh, Вы писали:
VC>Здравствуйте, gandjustas, Вы писали:
G>>На самом деле для человека, владеющего техниками оптимизации для SQL Server изучить оптимизацию для Postgres несложно, там примерно на порядок меньше вариантов операторов в плане, а множество типов индексов, которых нет в SQL Server, оптимизируют вполне конкретные функции. G>>Остается только разобраться с vacuum.
VC>На порядок, это сколько, в сравнении?
Примерно в 10 раз, ну может быть в 5.
VC>Я просто немного с mssql знаком (с postgres знаком очень хорошо), а вы похоже наоборот.
Я хорошо знаком с обоими системами
VC>Но я там не заметил на порядок большего количества типов шагов.
Сравни https://learn.microsoft.com/en-us/sql/relational-databases/showplan-logical-and-physical-operators-reference https://www.postgresql.org/docs/15/runtime-config-query.html (к сожалению только перечень флагов, отключающих те или иные операторы)
VC>в плане выполнения (про это я так понимаю речь?). А количество индексов в Постгресе не просто так, они для специфических типов данных (массивов, деревьев, geo координат и т.п.), которые отдельно в mssql не поддерживаются.
Что вы такое говорите. Геотипы в MS SQL с соответствующими индексами поддерживаются с 2016 версии (7 лет)
Столько же работает JSON в колонках (массивы, деревья).
А еще есть inmemory, columnstore, графовые таблицы, не говоря уже о ledger databases и historical tables
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, VladiCh, Вы писали:
VC>>Здравствуйте, gandjustas, Вы писали:
G>>>На самом деле для человека, владеющего техниками оптимизации для SQL Server изучить оптимизацию для Postgres несложно, там примерно на порядок меньше вариантов операторов в плане, а множество типов индексов, которых нет в SQL Server, оптимизируют вполне конкретные функции. G>>>Остается только разобраться с vacuum.
VC>>На порядок, это сколько, в сравнении? G>Примерно в 10 раз, ну может быть в 5.
Бред же. Часть из них при этом просто операторы T-SQL типа If и While.
Часть относится специфически к кластерным индексам, которых нет в Постгресе (он любые типы индексов вообще рассматривает одинаково в плане),
часть к Parallel и Remote выполнению (опять же все есть в Постгресе но нет отдельный nodes для них).
Да и я вообще не поленился посчитать — в Postgres формально 42 типа, в MSSQL 110. Не дотягивает даже до 3x, не то что 5x или 10x. https://github.com/postgres/postgres/blob/aa210e0c121eb8f58c86d4fcc833a5a6fbb6f5a9/src/backend/executor/execProcnode.c#L166 — можно тут посмотреть
А учитывая то что я написал выше там реально и 2x не будет.
В pl/pgsql тоже есть while в общем то и много что еще, но ты не найдешь этого в планах.
Всякие Adaptive Join там тоже есть но не в качестве отдельных элементов плана.
Вы тут сравниваете яблоки с апельсинами, как говорится.
VC>>Я просто немного с mssql знаком (с postgres знаком очень хорошо), а вы похоже наоборот. G>Я хорошо знаком с обоими системами
Это вообще тут ни причем.
VC>>в плане выполнения (про это я так понимаю речь?). А количество индексов в Постгресе не просто так, они для специфических типов данных (массивов, деревьев, geo координат и т.п.), которые отдельно в mssql не поддерживаются. G>Что вы такое говорите. Геотипы в MS SQL с соответствующими индексами поддерживаются с 2016 версии (7 лет) G>Столько же работает JSON в колонках (массивы, деревья).
G>А еще есть inmemory, columnstore, графовые таблицы, не говоря уже о ledger databases и historical tables
Что толку то от этих графовых таблиц, я про типы индексов говорю. Есть columnstore, ok (из того чего нет в Postgres), хотя есть extension для этого (и еще для 100500 других вещей)
В обратную сторону там 4-5 типов индексов есть которых нет в MSSQL.
