Hacker News Digest

PostgreSQL может быть как чтением, так и записью интенсивной в зависимости от бизнес-логики приложения. Для социальных сетей характерно чтение интенсивное, а для IoT логгеров — запись интенсивная. Определение профиля нагрузки критично для эффективной настройки: чтение интенсивные БД выигрывают от индексации, кэширования запросов и реплик, тогда как запись интенсивные требуют оптимизации хранилищ, управления WAL и дизайна таблиц.

Чтения и записи в PostgreSQL не равны по стоимости: чтение происходит 8kb блоками, часто из памяти, в то время как запись включает WAL, индексы, TOAST таблицы и требует больше ресурсов. Автор предлагает запрос для оценки соотношения чтения/записи на основе внутренних метаданных PostgreSQL, где по умолчанию используется соотношение 5:1 (чтение:запись).

• Обсуждение критикует статью за то, что она не сравнивает PostgreSQL с другими СУБД и не дает практических советов по тюнингу под конкретную нагрузку.
• Участники обсуждают, что статья не учитывает, что большинство приложений имеют смешанную нагрузку на чтение и запись, а не чисто чтение или запись.
• Некоторые комментаторы отмечают, что статья не упоминает OLTP и OLAP, что делает ее менее полезной для практического использования.
• Также обсуждается, что статья не дает ясного определения, что считается "read-heavy" или "write-heavy" в контексте PostgreSQL.
• Наконец, участники обсуждают, что статья не предоставляет конкретных советов по тюнингу PostgreSQL под конкретную нагрузку.

Оператор OR в SQL-запросах может быть неожиданно дорогим из-за сложностей планирования запросов. Например, запрос с OR для двух столбцов с индексами может выполняться более 100 мс на миллионе записей, в то время как эквивалентный запрос с использованием AND и подзапросов сокращает время до менее 1 мс. Это происходит потому, что оптимизатору сложно эффективно объединять результаты по индексам для условий OR, особенно при наличии дополнительных фильтров или сортировок.

Практическое решение — избегать OR в пользу денормализации данных. Например, вместо хранения нескольких внешних ключей в одной таблице можно создать отдельную таблицу связей, что упрощает запросы и ускоряет их выполнение за счёт линейных соединений. Это особенно важно для часто используемых операций, таких как поиск с множественными условиями.

• Обсуждаются проблемы производительности SQL-запросов с оператором OR, особенно при использовании предикатов по разным колонкам, и предлагается ручная оптимизация через переписывание в UNION ALL.
• Поднимается вопрос о сложности работы оптимизатора запросов, который может неправильно оценить количество строк из-за устаревшей статистики, что приводит к резкому росту сложности выполнения.
• Упоминаются различные техники индексирования (например, ESR для MongoDB) и важность правильного проектирования таблиц и индексов для избежания проблем с производительностью.
• Отмечается, что ORM часто генерируют неоптимальные запросы, и подчеркивается необходимость ручной проверки и настройки SQL, особенно в высоконагруженных системах.
• Обсуждается возможность применения машинного обучения и расширенной статистики в оптимизаторах запросов для улучшения оценки кардинальности и выбора более эффективных планов выполнения.