Comments 13
Ну, это, на самом деле, не проблема CTE.
Люди очень любят в любого рода подзапросах джоинить таблицу на саму себя с какими то расчитанными значениями…
Основной посыл — если таблица джоинится на себя по ключу — значит что то пошло не так. (ну это в общем случае)
Люди очень любят в любого рода подзапросах джоинить таблицу на саму себя с какими то расчитанными значениями…
Основной посыл — если таблица джоинится на себя по ключу — значит что то пошло не так. (ну это в общем случае)
Ну ничего себе вредные советы…
Во первый CTE в Oracle, MS SQL Server и PostgreSQL разный. И в первых двух ничего подобного множеству «CTE Scan» не будет — они прекрасно буферизируют результаты CTE запросов. Поэтому для Oracle и SQL Server, в некоторых кейсах наоборот выгодно вынести подзапрос в CTE выражение, чтобы избежать множества повторных чтений данных.
Во вторых, хотя бы версию PostgreSQL указали — может в следующей работу с CTE подправят, и таких «особенностей» уже не будет.
Ну и вообще причина такого поведения базы не в том, что она ваш запрос обработать не может, а в индивидуальных особенностях PostgreSQL. А там эти особенности от того, что её Enterprise вариации хвастают фичами прикрывающими эти проблемы — и переносить их в upstream не очень выгодно, хотя кое-что и просачивается.
Во первый CTE в Oracle, MS SQL Server и PostgreSQL разный. И в первых двух ничего подобного множеству «CTE Scan» не будет — они прекрасно буферизируют результаты CTE запросов. Поэтому для Oracle и SQL Server, в некоторых кейсах наоборот выгодно вынести подзапрос в CTE выражение, чтобы избежать множества повторных чтений данных.
Во вторых, хотя бы версию PostgreSQL указали — может в следующей работу с CTE подправят, и таких «особенностей» уже не будет.
Ну и вообще причина такого поведения базы не в том, что она ваш запрос обработать не может, а в индивидуальных особенностях PostgreSQL. А там эти особенности от того, что её Enterprise вариации хвастают фичами прикрывающими эти проблемы — и переносить их в upstream не очень выгодно, хотя кое-что и просачивается.
Я не говорил, что использовать CTE — плохо. Но вот джойнить их при больших размерах (конкретно в PG, конкретно во всех известных на данный момент версиях) — дорого. И если есть способ этого не делать, то лучше им воспользоваться.
Я согласен, что джоинить, при больших размерах — дорого. Но придти к этому выводу по вашей статье очень сложно. Заголовок и текст посвящены CTE, вывод общий, без упоминания джионов. Да и проблема с множественным «CTE Scan» операции Join все-же ну совсем ортогональна.
И вторая проблема в другом — если не считать упоминания блога PostgreSQL, то СУБД больше нигде не упомянута. Т.е., как-бы, по отдельному плану выполнения запросов (без указания СУБД и версии) Вы делаете обобщенный вывод про все БД в целом. И получается, что Ваша статья может легко ввести в заблуждение, если человек не обладает достаточным опытом.
На самом деле у Вас могла бы выйти очень хорошая статья. Нужно только немного конкретики — более явно указать СУБД и написать про её версии, сравнить с другими и написать, что это особенность PostgreSQL, указать, что может эту особенность исправят. В выводе отметить, что CTE x CTE в PostgreSQL может привести к такому эффекту, и вообще джоинить до фильтрации данных — плохо. Это и не вводило бы неопытных/невнимательных разработчиков в заблуждение и было бы хорошей отсылкой к Вашему https://explain.tensor.ru.
И вторая проблема в другом — если не считать упоминания блога PostgreSQL, то СУБД больше нигде не упомянута. Т.е., как-бы, по отдельному плану выполнения запросов (без указания СУБД и версии) Вы делаете обобщенный вывод про все БД в целом. И получается, что Ваша статья может легко ввести в заблуждение, если человек не обладает достаточным опытом.
На самом деле у Вас могла бы выйти очень хорошая статья. Нужно только немного конкретики — более явно указать СУБД и написать про её версии, сравнить с другими и написать, что это особенность PostgreSQL, указать, что может эту особенность исправят. В выводе отметить, что CTE x CTE в PostgreSQL может привести к такому эффекту, и вообще джоинить до фильтрации данных — плохо. Это и не вводило бы неопытных/невнимательных разработчиков в заблуждение и было бы хорошей отсылкой к Вашему https://explain.tensor.ru.
Заголовок и проблематика посвящены декартову произведению CTE. И такое положение дел сохранится, как минимум, следующие пару мажорных версий PG, а пока они доберутся до прода — то и на все лет 5 тема актуальна. Ну и я не делал выводов относительно "всех СУБД", пост же в профильный блог включен, и планы вполне конкретные.
А где было про джойн раньше фильтрации?
Здесь есть статьи, которым больше пяти лет. Все же, укажите Вы в тексте статьи версии PostgreSQL на которых это проверяли и было бы более информативно. Насчет выводов «всех СУБД» — пока вы не исправили заголовок и не появились комментарии на PostgreSQL указывала только одна маленькая ссылка под большим заголовком, которую просто пропустить. А для идентификации СУБД по планам, все же нужен опыт. Отсюда и вывод, что легко запутать неопытных/невнимательных читателей.
Насчет слов про фильтрацию — это отсылка к «джойнить их при больших размерах — плохо». Даже такой CTE x CTE в текущем PostgreSQL совсем не плох, если фильтрует данные и возвращает условный десяток строк. И это относится к любому join, не важно, чем он оперирует.
Насчет слов про фильтрацию — это отсылка к «джойнить их при больших размерах — плохо». Даже такой CTE x CTE в текущем PostgreSQL совсем не плох, если фильтрует данные и возвращает условный десяток строк. И это относится к любому join, не важно, чем он оперирует.
Проблема ровно в том, что CTE Scan из 10k записей будет гораздо медленнее, чем Index Scan из таблицы того же размера. А при 100 записях они будут занимать примерно одинаковый объем в памяти, и доступ к CTE тоже не будет быстрее. В силу того факта, что является неиндексированной структурой.
- видимо, после каждой фразы нужно добавлять дисклеймер, что речь только про PostgreSQL версий вплоть до 13, и, возможно, дальше :)
Думал, что это какой-то бред, пока не прочитал в комментариях, что это только про PostgreSQL
Sign up to leave a comment.
PostgreSQL Antipatterns: CTE x CTE