Comments 9
Отключение всех трёх JOIN ломает работу соединений, PostgreSQL выдаст ошибку.
Дивный новый мир: нейросеть что-то там нагенерила, автор даже не удосужился проверить.
Да, действительно, один из операторов нельзя отключить полностью
enable_hashjoin- Enables or disables the query planner's use of hash-join plan types. The default is on.
enable_mergejoin- Enables or disables the query planner's use of merge-join plan types. The default is on.
enable_nestloop- Enables or disables the query planner's use of nested-loop join plans. It is impossible to suppress nested-loop joins entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is on.https://www.postgresql.org/docs/17/runtime-config-query.html
Исправил статью, спасибо за наблюдение
Везде указаны EXPLAIN ANALYZE, но нет ни одного примера вывода. Надо было промпт дополнить. Ну или руками надёргать примеров.
В идеале было бы добавить планы запросов + пояснения к ним.
Но это ухудшило бы читабельность, т.к. планы различаются в основном ключевыми словами, вроде конкретного типа join.
Выбрал альтернативу - контекстные ссылки на эти самые ключевые слова
Но это ухудшило бы читабельность, т.к. планы различаются в основном ключевыми словами, вроде конкретного типа join.
Не знаю на кого рассчитана статья, но если на тех, кто только учится, то им как раз было бы полезно увидеть что именно из текста ANALYZE надо найти. Не просто "что искать", а прямо на примере "вот здесь есть строчка, вот так она выглядит, обратите внимание".
Ну и опять же, можно приводя примеры ответов, скрывать ненужные детали и оставить только ключевые моменты. Так или иначе, пример на что смотреть - не лишний.
Сейчас получается так - читаешь статью и что бы понять как это работает, надо обязательно сесть за рояль и самому накидать всяких примеров, что бы увидеть результат. С одной стороны - безусловно полезно закрепить на практике. С другой - посмотреть заранее что закреплять было бы лучше. Да и впечатление от статьи сложилось бы другое.
В целом хорошо описано, приятно читать, нет воды. Но вот этот момент, как мне кажется, не помешал бы.
а где латеральные джоины? Это же панацея для сращивания больших таблицы при узких выборках
вопрос по пункту ”Измерьте скорость случайного и последовательного чтения Выполните pg_test_timing“ Утилита pg_test_timing измеряет скорость получения меток времени. Может быть вы имели в виду другую утилиту
Хорошее замечание: pg_test_timing действительно не предназначен для оценки производительности доступа.
Однако в одном из обсуждений мэилинг листа PostgreSQL нашёл инфо, что если задержки велики, значит, сам процесс измерения времени в системе нестабилен или медленный - косвенный признак, что случайный доступ (который требует многократных обращений к диску) будет страдать от больших задержек.
Согласен, не лучший из возможных способов тестирования, однако другие утилиты требуют более глубокого погружения, а по-хорошему и вовсе отдельной статьи.
Добавил уточнения в статью
Оптимизация JOIN в PostgreSQL