Comments 5
Оптимизировать запрос в вакууме — просто. Но как он поведет себя, когда десятки таких же запросов одновременно борются за ресурсы?
О чём статья? О том как ведёт себя join с where на вакууме? Ой, простите, на какой-то там тестовой базе.
Не видно причин, не видно мыслей, не видно выводов и идей как вести себя если данные иначе распределены.
Лабораторная работа начального уровня.
Я правильно понимаю, что при каждом обращении к CTE random_period происходит сортировка по random всей таблицы bookings и только после выбирается первый как случайный? И так много раз
Расскажите, пожалуйста, по подробней про эту часть
SELECT
book_date AS start_date
FROM bookings
WHERE book_date <= (SELECT MAX(book_date) FROM bookings) - INTERVAL '30 days'
ORDER BY RANDOM()
LIMIT 1
) AS random_date
Какие подробности вас интересуют ?
Задача очень простая - получить случайную дату из периода.
Вы понимаете, что вы эти сортировки включаете в измерения, хотя, по факту, этот параметр должен приходить от пользователя? Ваши запросы и измерения некорректны - я вам на это указывал несколько раз.
Ну и вообще вся "сложная схема" базы данных у вас - это 9 табличек и 12 Gb? У меня есть таблицы в два раза больше этих 12Gb и это даже не big data. 12 Gb влезет даже в RAM на небольшом сервере. Перестаньте заниматься ерундой.
@moderator, а можно как-то ограничить поток автогенерированного псевдотехнического бреда от этого пользователя? Он засоряет всем ленту, отвлекает от нормальных статей..
Все предыдущие статьи заминусованы, на замечания автор не реагирует. Реального смысла во всех этих "измерениях" нет.
Анализ вариантов оптимизации ресурсоёмкого SQL-запроса: Вариант-5 «Условие WHERE»