Если сначала сделать \pset format unaligned, а потом \x, то, конечно, будет невыровненный вывод. Но если вернуть \pset format aligned, то \x все корректно и красиво выравнивает.
я бы еще добавил заполняемость партиций (насколько эффективно использовали "формулу" распределения) и еще можно прицепить статистику по партициям, к какой сколько больше обращались (какие горячие на момент построения)
Во-первых, автор указал, что решения он предложил для SQLite. Это как минимум нас приземляет на какой-то диалект SQL и формат вывода планов. Тут Вы видимо не очень внимательно читали.
Ну а то, что нужна схема данных, нужны данные, нужна статистика по этим данным это и так очевидные факты любого кто занимается анализом произаводительности запросов. Нет ничего проще это сделать и выложить хоть на гитхабе, чтобы любой мог повторить. И статья от этого только выиграет.
И не соглашусь с Вами... Заниматься оптизацией можно и нужно в любое время, хоть на модельных примерах, хоть на продуктовых данных. Это полезный труд, показывающий другим существенные детали для понимания процесса оптимизации запросов.
Спасибо за статью, но при обсуждении оптимизации запросов неплохо бы еще обсуждать планы получаемых запросов. Коротко и понятно написанный запрос не всегда является оптимальным с точки зрения базы - к сожалению.
Спасибо за статью. Всегда интересно читать материал на подобные темы. Но, все таки, отмечу некоторые недочеты, которые делают материал сложным и не системным для восприятия. Об этом уже выше упоминали.
Деревом запроса называется древовидная структура, в узлах которой расположены логические операторы, соответствующие отдельным операциям запроса.
Слово "логические" здесь требует расшифровки или уточнения. Ниже вы употребляете связку "физические" / "логические" операции, связывая с трансформациями, но в данном случае это сбивает с толку. Может просто "отдельные элементарные операции"?! А ниже уже расшифровывать на логические и физические, иначе возникает путаница с реальными логическими выражениями в условиях.
Более того, повествование к середине статьи уходит корнями только в JOIN-ы и их связь с теорией множеств и логикой. И слово "логический" в Вашем тексте становится крайне перегруженным, и каждый раз нужно себя заставлять понять, что же конкретно автор имеет в виду.
Разобравшись с тем, что такое дерево поиска, введем ещё два определения: логическая эквивалентность и область поиска.
В каком-то смысле план каждого SELECT-запрос действительно можно сравнить с неким деревом поиска. Но, честно говоря, - это двоякое понятие, особенно в контексте баз данных. Может все таки использовать "дерево разбора" или "дерево запроса", чтобы не было путаницы с реальными деревьями поиска. Тем более далее Вы снова употребляете фразу "...деревья запросов..."
Чтобы сократить количество логически эквивалентных выражений, их можно преобразовывать в так называемые групповые выражения. В каждом узле дерева такого выражения находится логический оператор, принимающий на вход группы эквивалентных запросов, а не просто отдельные запросы.
Вот это наверно самое сложное место статьи. Змея сама себя съела с хвоста. Намешано в кучу и логические выражения и запросы и все это завернутое само в себя на вход другому узлу. По контексту, конечно, можно догадаться, что Вы хотели сказать. Вы имели здесь в виду по большей части всякие JOIN-ы, что тесно связано и с теорией множеств и с логикой (SQL JOINS on Euler/Venn Diagramms).
Но слова выбраны, на мой взгляд, неподходящие. Очень сложно читать. Как улучшить, не знаю. Наверно только переписать заново, точно поняв набор каких понятий (введенных выше) использовать, заранее обозначить, что все повествование статьи идет в контексте JOIN.
Вероятно Вы это взяли из какой-то книжки. Тогда лучше процитировать автора повествования теории в таком виде, чтобы все таки разобраться в понятиях.
Очевидно, что при таком подходе выбор оптимального плана выродится в полный перебор всех вариантов, поэтому для использования на практике его нужно модифицировать.
Превратиться?! ))
for a in A: if (contains(B, a)): return a x b
return надо бы подвинуть. Ну и если вы хотите вернуть пару (кортеж), а здесь именно это и предполагается, то это лучше как-то обозначить без применения оператора декартова произведения по отношению к элементам множества.
В заголовке таблицы ошибка: barnam вместо barman
Поправьте в статье, пожалуйста.
Если сначала сделать \pset format unaligned, а потом \x, то, конечно, будет невыровненный вывод. Но если вернуть \pset format aligned, то \x все корректно и красиво выравнивает.
я бы еще добавил заполняемость партиций (насколько эффективно использовали "формулу" распределения) и еще можно прицепить статистику по партициям, к какой сколько больше обращались (какие горячие на момент построения)
Во-первых, автор указал, что решения он предложил для SQLite. Это как минимум нас
приземляет на какой-то диалект SQL и формат вывода планов. Тут Вы видимо не очень внимательно читали.
Ну а то, что нужна схема данных, нужны данные, нужна статистика по этим данным
это и так очевидные факты любого кто занимается анализом произаводительности запросов.
Нет ничего проще это сделать и выложить хоть на гитхабе, чтобы любой мог повторить.
И статья от этого только выиграет.
И не соглашусь с Вами... Заниматься оптизацией можно и нужно в любое время, хоть на модельных примерах,
хоть на продуктовых данных. Это полезный труд, показывающий другим существенные детали
для понимания процесса оптимизации запросов.
Спасибо за статью, но при обсуждении оптимизации запросов неплохо бы еще обсуждать планы получаемых запросов. Коротко и понятно написанный запрос не всегда является оптимальным с точки зрения базы - к сожалению.
Осталась за кадром еще одна очень важная вещь - какая-либо реализация "слоеной" файловой системы (overlayfs, aufs, unionfs, ...).
Коллеги вы показываете скрины с PG14 и recovery.conf
Но уже начиная с PG14 recovery.conf влили в postgresql.conf и при наличии этого файла сервер не запуститься.
https://www.postgresql.org/docs/14/recovery-config.html
Опечатка? Или я чего-то невнимательно читал?!
Спасибо за статью. Всегда интересно читать материал на подобные темы. Но, все таки, отмечу некоторые недочеты, которые делают материал сложным и не системным для восприятия. Об этом уже выше упоминали.
Слово "логические" здесь требует расшифровки или уточнения. Ниже вы употребляете связку "физические" / "логические" операции, связывая с трансформациями, но в данном случае это сбивает с толку. Может просто "отдельные элементарные операции"?! А ниже уже расшифровывать на логические и физические, иначе возникает путаница с реальными логическими выражениями в условиях.
Более того, повествование к середине статьи уходит корнями только в JOIN-ы и их связь с теорией множеств и логикой. И слово "логический" в Вашем тексте становится крайне перегруженным, и каждый раз нужно себя заставлять понять, что же конкретно автор имеет в виду.
В каком-то смысле план каждого SELECT-запрос действительно можно сравнить с неким деревом поиска. Но, честно говоря, - это двоякое понятие, особенно в контексте баз данных. Может все таки использовать "дерево разбора" или "дерево запроса", чтобы не было путаницы с реальными деревьями поиска. Тем более далее Вы снова употребляете фразу "...деревья запросов..."
Вот это наверно самое сложное место статьи. Змея сама себя съела с хвоста. Намешано в кучу и логические выражения и запросы и все это завернутое само в себя на вход другому узлу. По контексту, конечно, можно догадаться, что Вы хотели сказать. Вы имели здесь в виду по большей части всякие JOIN-ы, что тесно связано и с теорией множеств и с логикой (SQL JOINS on Euler/Venn Diagramms).
Но слова выбраны, на мой взгляд, неподходящие. Очень сложно читать. Как улучшить, не знаю. Наверно только переписать заново, точно поняв набор каких понятий (введенных выше) использовать, заранее обозначить, что все повествование статьи идет в контексте JOIN.
Вероятно Вы это взяли из какой-то книжки. Тогда лучше процитировать автора повествования теории в таком виде, чтобы все таки разобраться в понятиях.
Превратиться?! ))
return надо бы подвинуть. Ну и если вы хотите вернуть пару (кортеж), а здесь именно это и предполагается, то это лучше как-то обозначить без применения оператора декартова произведения по отношению к элементам множества.
Тоже самое съехали отступы ниже.