digital-garden/_inbox/JOIN SQL.md

2.1 KiB
Raw Blame History

aliases tags date zero-link parents linked
зрелость/🌱
2024-02-05
00 SQL

Postgres имеет три основных алгоритма Join'а, а именно

  • Nested Loop. Берем данные из одной таблицы и циклами их Join'им
  • Hash index. Одна, чаще маленькая, таблица хэшируется и по этому хэшу Join'ится с другой таблицей
  • Merge Join.
SELECT * FROM posts WHERE author = "Peter"
JOIN comments ON posts. id = comments.post_id

Индекс по posts.id бесполезен. Индекс по comments.post_id обязателен. Если вы создадите индекс, оптимизатор выберет Nested Loop, и все будет работать быстро.

Почему JOIN работает медленно?

  • Индекс для полей по которым джойним добавлен?

Заметки

  • B MySQL используется метод nested loops, но с оптимизациями.
  • У вас оптимизатор из каких-то соображений выбирает Nested Loop, а вам кажется, что одна таблица очень маленькая, другая очень большая и Hash Join там был бы очень уместен, потому что маленькую таблицу можно быстро прохэшировать и быстро с ней работать. Посмотрите, сколько у вас work mem'а. т.е. сколько памяти может занять один worker Postgresа. Если эта таблица хэшируется в, например, 100 Мб, а у вас work mem'а выдано только 30 Мб, то worker будет работать медленно. Если вы добавите work mem'а и хэширование начнет вмещаться в память, оптимизатор выберет правильный Hash Join и будет быстро и хорошо.