"Спасибо за комментарий! Да, при сравнении литерала varchar = bigint PostgreSQL выдаст ошибку. В примере я описывал ситуацию, которая чаще всего встречается в приложениях — когда значение приходит как параметр, и ORM передаёт его в «неправильном» типе (обычно как BIGINT). В этом случае PostgreSQL уже приводит колонку к типу параметра, и индекс перестаёт использоваться.
Действительно обновление статистики помогает, но не всегда спасает. Есть запросы, где планировщик в принципе не может выбрать идеальный план, и тогда без ручного вмешательства не обойтись. Просто в рамках гайда я сосредоточился на более типичных сценариях, с которыми чаще всего сталкиваются начинающие."
Спасибо за комментарий — вы верно подметили важный технический нюанс. В статье автор сознательно сосредоточился на базовых приёмах оптимизации: как по возможности уйти от Seq Scan к Index Scan, проверить актуальность статистики и сделать простой рефакторинг запросов. Эти шаги дают первые ощутимые улучшения без погружения в тонкости внутренних процессов СУБД. Тема Index Only Scan и его деградации из-за устаревшей visibility map, на мой взгляд, — уже более продвинутый уровень. Важность работы autovacuum автора отметил, но детали его механизмов оставил за рамками, чтобы не перегружать читателя на начальном этапе.
Спасибо за комментарий. В этой статье автор больше сфокусировался на инструментах поиска потенциально тяжёлых запросов, оставив оценку их реальной критичности на усмотрение разработчика или DBA. А так, вы верно подметили: медленный запрос не всегда является проблемой — например, в случае аналитических отчётов или batch-обработки длительное выполнение может быть ожидаемым.
Интересное замечание! Я использовал формулировку "слева направо" как общее упрощение для описания потока данных в конкретном примере, но вы правы: это не универсальное правило. Как я понял, порядок зависит от стратегии выполнения: при Hash Join первым часто отрабатывает правый узел (построение хэша), а при Nested Loop — левый. И соответственно, выполнение может идти в любую сторону в зависимости от выбранного планировщиком алгоритма. Спасибо, что затронули эту интересную техническую деталь!
Большое спасибо за внимательное чтение! Да, действительно, допущена неточность в формулировках "Bitmap Scan" и "Bitmap Index Scan". Исправили этот момент. Спасибо за помощь в улучшении статьи!
Большое спасибо за внимательное чтение! Вы абсолютно правы насчет опции SETTINGS. Она не меняет никакие параметры. Исправили этот абзац, чтобы не вводить читателей в заблуждение. Спасибо за помощь в улучшении статьи!
Отвечает автор текста: Хороший вопрос. Я сделал акцент на возможных случаях, когда из-за неточных оценок планировщик вынужден перебирать больше вариантов соединения таблиц, особенно в сложных запросах с большим количеством JOIN. Также, если он часто обращается к статистике, это может требовать декомпрессию данных из системных таблиц, что добавляет накладные расходы на этапе планирования. Но в целом, основное влияние статистики — это всё-таки время выполнения (качество плана). А вот на время планирования сильнее влияет сложность самого запроса.
посмотрите, у вас в предустановленном ПО, скорее всего, панель выбрана, без нее стоимость будет 4548, а на панель скидка не распространяется, только 1 месяц бесплатный
Механика такова, потому что без авторизации призы не смогут найти своего героя) Так у нас есть в игре ежедневные задания. И мы не сможем отследить, если неавторизованный пользователь сегодня зайдет в игру из офиса, завтра из дома, в выходные, например, с мобильника) А авторизация для всех одинаковая.
В условиях акции прописаны максимальные сроки, чтобы авторы понимали, сколько в принципе может быть ожидание. Но у нас нет задачи растягивать проверку материалов - тут многое будет зависеть от нагрузки на редактора в целом :) Также и со сроком публикации материалов - указан максимально возможный, если желающих будет много. Если вам критично, чтобы срок между согласованием статьи и публикацией был не очень большим, то вы можете это в индивидуальном порядке обговорить с редактором. О дате публикации мы всегда авторам говорим сразу после согласования статьи.
В дата-центре Qupra DC2 проблема с чиллерами. Устраняем. Следить за статусом можно тут — https://firstvds.live.
Спасибо за комментарий. Добавили ссылку.
Добрый день!
Отвечает автор:
"Спасибо за комментарий! Да, при сравнении литерала varchar = bigint PostgreSQL выдаст ошибку. В примере я описывал ситуацию, которая чаще всего встречается в приложениях — когда значение приходит как параметр, и ORM передаёт его в «неправильном» типе (обычно как BIGINT). В этом случае PostgreSQL уже приводит колонку к типу параметра, и индекс перестаёт использоваться.
Действительно обновление статистики помогает, но не всегда спасает. Есть запросы, где планировщик в принципе не может выбрать идеальный план, и тогда без ручного вмешательства не обойтись. Просто в рамках гайда я сосредоточился на более типичных сценариях, с которыми чаще всего сталкиваются начинающие."
Спасибо за комментарий — вы верно подметили важный технический нюанс. В статье автор сознательно сосредоточился на базовых приёмах оптимизации: как по возможности уйти от Seq Scan к Index Scan, проверить актуальность статистики и сделать простой рефакторинг запросов. Эти шаги дают первые ощутимые улучшения без погружения в тонкости внутренних процессов СУБД. Тема Index Only Scan и его деградации из-за устаревшей visibility map, на мой взгляд, — уже более продвинутый уровень. Важность работы autovacuum автора отметил, но детали его механизмов оставил за рамками, чтобы не перегружать читателя на начальном этапе.
так, вроде теперь должно заработать, посмотрите, пожалуйста)
Спасибо за комментарий. В этой статье автор больше сфокусировался на инструментах поиска потенциально тяжёлых запросов, оставив оценку их реальной критичности на усмотрение разработчика или DBA. А так, вы верно подметили: медленный запрос не всегда является проблемой — например, в случае аналитических отчётов или batch-обработки длительное выполнение может быть ожидаемым.
Добрый день!
Вроде ссылка работает, но вот еще продублирую на всякий случай)
https://habr.com/ru/companies/first/articles/1006278/
Спасибо, что обратили внимание! Внесли правку)
Отвечает автор текста:
Интересное замечание! Я использовал формулировку "слева направо" как общее упрощение для описания потока данных в конкретном примере, но вы правы: это не универсальное правило. Как я понял, порядок зависит от стратегии выполнения: при Hash Join первым часто отрабатывает правый узел (построение хэша), а при Nested Loop — левый. И соответственно, выполнение может идти в любую сторону в зависимости от выбранного планировщиком алгоритма. Спасибо, что затронули эту интересную техническую деталь!
Большое спасибо за внимательное чтение! Да, действительно, допущена неточность в формулировках "Bitmap Scan" и "Bitmap Index Scan". Исправили этот момент. Спасибо за помощь в улучшении статьи!
Большое спасибо за внимательное чтение! Вы абсолютно правы насчет опции SETTINGS. Она не меняет никакие параметры. Исправили этот абзац, чтобы не вводить читателей в заблуждение. Спасибо за помощь в улучшении статьи!
Отвечает автор текста:
Хороший вопрос. Я сделал акцент на возможных случаях, когда из-за неточных оценок планировщик вынужден перебирать больше вариантов соединения таблиц, особенно в сложных запросах с большим количеством JOIN. Также, если он часто обращается к статистике, это может требовать декомпрессию данных из системных таблиц, что добавляет накладные расходы на этапе планирования. Но в целом, основное влияние статистики — это всё-таки время выполнения (качество плана). А вот на время планирования сильнее влияет сложность самого запроса.
Спасибо за дополнения!
спасибо за идею, подумаем по поводу этой темы)
В статью тоже внесли :)
Спасибо за внимательность, действительно ошиблись. Заменили на пример с годом рождения Торвальдса :)
посмотрите, у вас в предустановленном ПО, скорее всего, панель выбрана, без нее стоимость будет 4548, а на панель скидка не распространяется, только 1 месяц бесплатный
Механика такова, потому что без авторизации призы не смогут найти своего героя) Так у нас есть в игре ежедневные задания. И мы не сможем отследить, если неавторизованный пользователь сегодня зайдет в игру из офиса, завтра из дома, в выходные, например, с мобильника) А авторизация для всех одинаковая.
В условиях акции прописаны максимальные сроки, чтобы авторы понимали, сколько в принципе может быть ожидание. Но у нас нет задачи растягивать проверку материалов - тут многое будет зависеть от нагрузки на редактора в целом :) Также и со сроком публикации материалов - указан максимально возможный, если желающих будет много. Если вам критично, чтобы срок между согласованием статьи и публикацией был не очень большим, то вы можете это в индивидуальном порядке обговорить с редактором. О дате публикации мы всегда авторам говорим сразу после согласования статьи.
отлично)