Сообщение Re[5]: постгресс ненависти псто №2 от 09.12.2023 0:39
Изменено 09.12.2023 15:11 VladiCh
Re[5]: постгресс ненависти псто №2
Здравствуйте, 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>>Но я там не заметил на порядок большего количества типов шагов.
G>Сравни
G>https://learn.microsoft.com/en-us/sql/relational-databases/showplan-logical-and-physical-operators-reference
G>https://www.postgresql.org/docs/15/runtime-config-query.html (к сожалению только перечень флагов, отключающих те или иные операторы)
Это вообще тут ни причем.
VC>>в плане выполнения (про это я так понимаю речь?). А количество индексов в Постгресе не просто так, они для специфических типов данных (массивов, деревьев, geo координат и т.п.), которые отдельно в mssql не поддерживаются.
G>Что вы такое говорите. Геотипы в MS SQL с соответствующими индексами поддерживаются с 2016 версии (7 лет)
G>Столько же работает JSON в колонках (массивы, деревья).
G>А еще есть inmemory, columnstore, графовые таблицы, не говоря уже о ledger databases и historical tables
Что толку то от этих графовых таблиц, я про типы индексов говорю. Есть columnstore, ok (из того чего нет в Postgres)
В обратную сторону там 4-5 типов индексов есть которых нет в MSSQL.
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>>Но я там не заметил на порядок большего количества типов шагов.
G>Сравни
G>https://learn.microsoft.com/en-us/sql/relational-databases/showplan-logical-and-physical-operators-reference
G>https://www.postgresql.org/docs/15/runtime-config-query.html (к сожалению только перечень флагов, отключающих те или иные операторы)
Это вообще тут ни причем.
VC>>в плане выполнения (про это я так понимаю речь?). А количество индексов в Постгресе не просто так, они для специфических типов данных (массивов, деревьев, geo координат и т.п.), которые отдельно в mssql не поддерживаются.
G>Что вы такое говорите. Геотипы в MS SQL с соответствующими индексами поддерживаются с 2016 версии (7 лет)
G>Столько же работает JSON в колонках (массивы, деревья).
G>А еще есть inmemory, columnstore, графовые таблицы, не говоря уже о ledger databases и historical tables
Что толку то от этих графовых таблиц, я про типы индексов говорю. Есть columnstore, ok (из того чего нет в Postgres)
В обратную сторону там 4-5 типов индексов есть которых нет в MSSQL.
Re[5]: постгресс ненависти псто №2
Здравствуйте, 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>>Но я там не заметил на порядок большего количества типов шагов.
G>Сравни
G>https://learn.microsoft.com/en-us/sql/relational-databases/showplan-logical-and-physical-operators-reference
G>https://www.postgresql.org/docs/15/runtime-config-query.html (к сожалению только перечень флагов, отключающих те или иные операторы)
Это вообще тут ни причем.
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.
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>>Но я там не заметил на порядок большего количества типов шагов.
G>Сравни
G>https://learn.microsoft.com/en-us/sql/relational-databases/showplan-logical-and-physical-operators-reference
G>https://www.postgresql.org/docs/15/runtime-config-query.html (к сожалению только перечень флагов, отключающих те или иные операторы)
Это вообще тут ни причем.
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.