Я понял, что это панель управления какая-то. Но такими штуками не пользуюсь, руками всё настраиваю

Для этого надо верхнее образование по nginx’у иметь, а людям некогда.

Какой самый правильный способ убрать юзеров где значения не совпали ?

Вы хотите INNER JOIN?

А с INNER работает как надо, всё рано никак не понимаю разницу, я думал left right inner влияют на сами столбцы, а не на то что в них записано

ну ладно, спасибо

вы вообще не понимаете что пишете. подтяните теорию

Привет, с какой книги лучше начать новичку? Спасибо.


Practical SQL: A Beginner's Guide to Storytelling with Data (2018)
Автор: Anthony DeBarros

Или

SQL in 10 Minutes a Day, Sams Teach Yourself, 5th Edition (2019)
Автор: Ben Forta

Какиета забугорные писания.. я бы посоветовал моргунова)

Пасиба)

Есть божественная книжка «Nginx. From beginner to pro”. Меня на первых главах обстебывали в чатике nginx, а потом какому-то индусу конфиг собирал уже сам))) это при том, что я не дочитал )))

У меня есть верхнее образование по nginx. Хорошая операционная система. Почти как постгрес.

Моргунова удваиваю. Новиков в целом - тот же Моргунов, но там более продвинутые темы потом поднимаются (хранимые процедуры и вот это вот всё).

Да, nginx это целая вселенная, не спорю )))

Сам разбирался по его учебному пособию, очень доходчиво и просто даёт простые вещи.

👍

Теперь у меня рядом с enable_mergejoin = off еще и enable_hashjoin = off. Глобально на весь инстанс, потому что лень было приложение ковырять. Смех и слезы. Ничего не сломалось и не просело, проблемы с зависшими запросами ушли. Наконец-то я понял, как правильно тюнить базу!

Вот изобретаю я, например, электронную почту.
Делаю таблицу messages (user_id, date).
Делаю индекс по (user_id, date DESC) и каждый раз показываю пользоватлю SELECT ... WHERE user_id = ... ORDER BY date DESC LIMIT 50.
Сообщений у каждого пользователя может быть 100, а может быть 100 000.
Все хорошо, покудова я эти сообщения с какой-нибудь маленькой второстепенной ерундой не начинаю джоинить. И хана. Планировщик вместо index scan и nested loop делает bitmap index scan → hash join → sort. В итоге пользователь со 100 000 сообщений отваливается по таймауту.

А зачем 100к сообщений за раз доставать из БД?

Ну вот пойду я сейчас статистику накатывать и надееться, что планировщик от этого поумнеет. Только зачем мне это надо, когда у меня все работает уже вчера.

Не 100 000, а LIMIT 50.