Топ причин, почему Postgres не использует индекс:
Его просто нет.
WHERE отбирает больше 5–10% строк. В такой ситуации Postgres выбирает последовательное сканирование, потому что накладные расходы на работу с индексом будут выше.
Планировщик работает со старыми статистиками. Такое бывает после массовой вставки, крупных UPDATE/DELETE, долгого отсутствия VACUUM или при недавно созданных индексах.
Таблица слишком маленькая. Последовательное сканирование в таком случае быстрее, чем использование индекса с его оверхедом.
Несовпадение типа индекса или использование функций над колонками, по которым есть индекс. Например LOWER(email).
Так что если планировщик не использует индекс — почти всегда он делает это потому, что так дешевле по стоимости запроса.
Надеюсь, пригодится.
👉 @SQLPortal
Его просто нет.
WHERE отбирает больше 5–10% строк. В такой ситуации Postgres выбирает последовательное сканирование, потому что накладные расходы на работу с индексом будут выше.
Планировщик работает со старыми статистиками. Такое бывает после массовой вставки, крупных UPDATE/DELETE, долгого отсутствия VACUUM или при недавно созданных индексах.
Таблица слишком маленькая. Последовательное сканирование в таком случае быстрее, чем использование индекса с его оверхедом.
Несовпадение типа индекса или использование функций над колонками, по которым есть индекс. Например LOWER(email).
Так что если планировщик не использует индекс — почти всегда он делает это потому, что так дешевле по стоимости запроса.
Надеюсь, пригодится.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍5
Производительность PostGIS: предикаты пересечения и оверлеи. Новая статья от Пола Рэмзи.
В чём разница между булевыми ST_Intersects и ST_Contains и операциями оверлея ST_Intersection и ST_Difference?
Сегодня разберем самые эффективные подходы к выборке объектов внутри других объектов.
Обычно мелкие геометрии обрезаются по границе с помощью ST_Intersection.
Наивный SQL — это обычный spatial join по ST_Intersects:
На небольшом тестовом наборе, как на картинках, запрос выполняется примерно за 14 мс. Это быстро, но задача маленькая, т.е. на больших данных будет заметно медленнее.
Есть простой способ ускорить запрос, используя то, что булевые пространственные предикаты работают быстрее, чем операции пространственного оверлея.
Что это значит?
Булевые пространственные предикаты - это функции вроде ST_Intersects и ST_Contains. Они принимают две геометрии и возвращают true/false в зависимости от результата проверки.
Операции пространственного оверлея . вроде ST_Intersection или ST_Difference - получают две геометрии и генерируют новую.
Предикаты быстрее, потому что могут прерывать проверку заранее (например, если найдены пересекающиеся ребра, значит геометрии пересекаются) и потому что используют оптимизации prepared geometry с кешированием структуры ребер.
Ускорение работы с оверлеями основано на простой идее = многие объекты вообще не нужно клиппать, если они полностью внутри полигональной границы. Их можно определить с помощью ST_Contains.
Есть и меньшая группа объектов, которые пересекают границу, их уже нужно обрабатывать через ST_Intersection — те, что ST_Intersects, но не ST_Contains.
Более быстрый запрос использует предикаты, чтобы разделить объекты на две категории: полностью внутри (оставляем как есть) и пересекающие границу (клиппим).
Здесь используются два предиката:
– ST_Intersects в join выбирает только кандидатов для обработки
– ST_Contains внутри CASE пропускает геометрии, которые не нужно клиппить
На том же тестовом наборе запрос выполняется примерно за 9 мс - разница настолько заметна, что её видно даже на маленьком примере.
Главная идея = булевые пространственные проверки (ST_Contains, ST_Intersects) значительно дешевле, чем операции вроде ST_Intersection. Обычный подход клиппит все пересекающиеся геометрии. Оптимизированный вариант использует CASE и ST_Contains, чтобы сделать shortcut: если объект полностью внутри. то просто возвращаем его без изменений и не вызываем дорогой ST_Intersection.
Этот шаблон можно применять во всех задачах в PostGIS, где есть клиппинг, spatial join или overlay, и где часть объектов ожидаемо находится целиком внутри границ.
Разделяя данные на два потока — «полностью внутри» (быстрый путь) и «пересекает» (медленный путь), мы гарантируем, что дорогостоящая геометрическая обработка выполняется только там, где она реально нужна.
👉 @SQLPortal
В чём разница между булевыми ST_Intersects и ST_Contains и операциями оверлея ST_Intersection и ST_Difference?
Сегодня разберем самые эффективные подходы к выборке объектов внутри других объектов.
Обычно мелкие геометрии обрезаются по границе с помощью ST_Intersection.
Наивный SQL — это обычный spatial join по ST_Intersects:
SELECT ST_Intersection(polygon.geom, p.geom) AS geom
FROM parcels p
JOIN polygon
ON ST_Intersects(polygon.geom, p.geom);
На небольшом тестовом наборе, как на картинках, запрос выполняется примерно за 14 мс. Это быстро, но задача маленькая, т.е. на больших данных будет заметно медленнее.
Есть простой способ ускорить запрос, используя то, что булевые пространственные предикаты работают быстрее, чем операции пространственного оверлея.
Что это значит?
Булевые пространственные предикаты - это функции вроде ST_Intersects и ST_Contains. Они принимают две геометрии и возвращают true/false в зависимости от результата проверки.
Операции пространственного оверлея . вроде ST_Intersection или ST_Difference - получают две геометрии и генерируют новую.
Предикаты быстрее, потому что могут прерывать проверку заранее (например, если найдены пересекающиеся ребра, значит геометрии пересекаются) и потому что используют оптимизации prepared geometry с кешированием структуры ребер.
Ускорение работы с оверлеями основано на простой идее = многие объекты вообще не нужно клиппать, если они полностью внутри полигональной границы. Их можно определить с помощью ST_Contains.
Есть и меньшая группа объектов, которые пересекают границу, их уже нужно обрабатывать через ST_Intersection — те, что ST_Intersects, но не ST_Contains.
Более быстрый запрос использует предикаты, чтобы разделить объекты на две категории: полностью внутри (оставляем как есть) и пересекающие границу (клиппим).
SELECT
CASE
WHEN ST_Contains(polygon.geom, p.geom) THEN p.geom
ELSE ST_Intersection(polygon.geom, p.geom)
END AS geom
FROM parcels p
JOIN polygon
ON ST_Intersects(polygon.geom, p.geom);
Здесь используются два предиката:
– ST_Intersects в join выбирает только кандидатов для обработки
– ST_Contains внутри CASE пропускает геометрии, которые не нужно клиппить
На том же тестовом наборе запрос выполняется примерно за 9 мс - разница настолько заметна, что её видно даже на маленьком примере.
Суть подхода: комбинируем предикаты и оверлеи через CASE
Главная идея = булевые пространственные проверки (ST_Contains, ST_Intersects) значительно дешевле, чем операции вроде ST_Intersection. Обычный подход клиппит все пересекающиеся геометрии. Оптимизированный вариант использует CASE и ST_Contains, чтобы сделать shortcut: если объект полностью внутри. то просто возвращаем его без изменений и не вызываем дорогой ST_Intersection.
Этот шаблон можно применять во всех задачах в PostGIS, где есть клиппинг, spatial join или overlay, и где часть объектов ожидаемо находится целиком внутри границ.
Разделяя данные на два потока — «полностью внутри» (быстрый путь) и «пересекает» (медленный путь), мы гарантируем, что дорогостоящая геометрическая обработка выполняется только там, где она реально нужна.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2
Вопрос по SQL:
Какой результат вернёт этот запрос?
Посмотрим, кто хорошо знает агрегатные функции.
Объясни свой ответ.
👉 @SQLPortal
Какой результат вернёт этот запрос?
Посмотрим, кто хорошо знает агрегатные функции.
Объясни свой ответ.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤4
This media is not supported in your browser
VIEW IN TELEGRAM
Появилась интересная новинка для тех, кто постоянно работает с данными и устал писать SQL вручную. Вышел OpenChatBI — опенсорсный BI инструмент, который позволяет делать запросы к базе обычным языком и получать результат в виде таблиц или графиков.
Инструмент построен на LangGraph и LangChain, умеет превращать текстовые запросы в SQL и автоматически их выполнять. Для сложных вопросов можно подключить внешние источники знаний или расширить функциональность через MCP.
У OpenChatBI есть удобный Web UI, а установка занимает пару минут — достаточно поставить через pip или uv, подключить базу и настроить LLM.
Репозиторий здесь: https://github.com/zhongyu09/openchatbi
👉 @SQLPortal
Инструмент построен на LangGraph и LangChain, умеет превращать текстовые запросы в SQL и автоматически их выполнять. Для сложных вопросов можно подключить внешние источники знаний или расширить функциональность через MCP.
У OpenChatBI есть удобный Web UI, а установка занимает пару минут — достаточно поставить через pip или uv, подключить базу и настроить LLM.
Репозиторий здесь: https://github.com/zhongyu09/openchatbi
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍2🤔1
Типичные проблемы при очистке данных в SQL и как их решать
👉 @SQLPortal
Удаление дубликатов
├── Использование DISTINCT
└── Использование ROW_NUMBER()
Обработка пропущенных значений
├── Фильтрация NULL
└── Замена NULL
Стандартизация данных
├── Приведение типов
└── Форматирование данных
Удаление выбросов
├── Фильтрация по условиям
└── Применение статистических методов
Исправление опечаток
├── Использование UPDATE
└── Использование CASE
Нормализация данных
├── Создание lookup-таблиц
└── Разделение колонок
Обработка разнородных данных
├── Использование CASE WHEN
└── Использование REPLACE
Парсинг данных
├── Использование SUBSTRING
└── Использование CHARINDEX
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3
Производительные или и выгодные базы данных в облаке
Безопасные, масштабируемые и отказоустойчивые базы данных — одна из ключевых потребностей любого проекта. Именно такие предлагает Selectel. СУБД под разные запросы: от универсальной PostgreSQL до поисковой и аналитической БД Opensearch
Новые клиенты сейчас могут получить до 30 000 бонусов на использование облачных баз данных Selectel. Провайдер гарантирует:
🔹Высокую производительность. Выбирайте оптимальную конфигурацию кластера на базе мощного железа и локальных NVMe-дисков.
🔹Надежность. Автоматические бесплатные бэкапы с восстановлением вплоть до секунды — на стороне Selectel. А создать отказоустойчивый кластер можно всего от двух нод и сэкономить до 33%.
🔹Гибкое масштабирование. При росте нагрузки можно поменять конфигурацию облачного сервера и количество реплик без простоя.
Успейте зарегистрироваться и оставить заявку на участие в акции, чтобы протестировать сервис бесплатно: https://slc.tl/swsly
Реклама. АО "Селектел". erid:2W5zFHExKcc
Безопасные, масштабируемые и отказоустойчивые базы данных — одна из ключевых потребностей любого проекта. Именно такие предлагает Selectel. СУБД под разные запросы: от универсальной PostgreSQL до поисковой и аналитической БД Opensearch
Новые клиенты сейчас могут получить до 30 000 бонусов на использование облачных баз данных Selectel. Провайдер гарантирует:
🔹Высокую производительность. Выбирайте оптимальную конфигурацию кластера на базе мощного железа и локальных NVMe-дисков.
🔹Надежность. Автоматические бесплатные бэкапы с восстановлением вплоть до секунды — на стороне Selectel. А создать отказоустойчивый кластер можно всего от двух нод и сэкономить до 33%.
🔹Гибкое масштабирование. При росте нагрузки можно поменять конфигурацию облачного сервера и количество реплик без простоя.
Успейте зарегистрироваться и оставить заявку на участие в акции, чтобы протестировать сервис бесплатно: https://slc.tl/swsly
Реклама. АО "Селектел". erid:2W5zFHExKcc
👍2🔥1
Мои топ-5 советов по оптимизации Postgres для разработчиков:
- научись пользоваться EXPLAIN. Он покажет, как именно выполняется запрос и где его можно подтюнить.
- понимай, когда нужны индексы. Смотри пункт выше, чтобы убедиться, что индекс реально решает проблему. Не переборщи с индексами, но и не забивай на них.
- используй connection pooling. В Postgres его нет из коробки, и для каждого подключения поднимается отдельный процесс. Используй серверный или клиентский пул, а лучше оба. Просто используй что-то.
- запрашивай только то, что надо. Избегай SELECT * FROM. Будь точнее SELECT column1, column2 FROM. Не трать ресурсы на данные, которые твоему приложению не нужны.
- используй вычислительные возможности базы. Хочется вытащить данные и обработать их в приложении, но часто быстрее сделать агрегацию, сортировку и другую тяжёлую работу в SQL. И да, абсолютно нормально писать хранимые процедуры для тяжёлых вычислительных или данных задач.
👉 @SQLPortal
- научись пользоваться EXPLAIN. Он покажет, как именно выполняется запрос и где его можно подтюнить.
- понимай, когда нужны индексы. Смотри пункт выше, чтобы убедиться, что индекс реально решает проблему. Не переборщи с индексами, но и не забивай на них.
- используй connection pooling. В Postgres его нет из коробки, и для каждого подключения поднимается отдельный процесс. Используй серверный или клиентский пул, а лучше оба. Просто используй что-то.
- запрашивай только то, что надо. Избегай SELECT * FROM. Будь точнее SELECT column1, column2 FROM. Не трать ресурсы на данные, которые твоему приложению не нужны.
- используй вычислительные возможности базы. Хочется вытащить данные и обработать их в приложении, но часто быстрее сделать агрегацию, сортировку и другую тяжёлую работу в SQL. И да, абсолютно нормально писать хранимые процедуры для тяжёлых вычислительных или данных задач.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥1
Миграция с MS SQL, Oracle и PostgreSQL проходит почти сама собой – возможно ли это? 🤔
📍Короткий ответ: Да.
Диасофт обновил свою СУБД Digital Q.DataBase, чтобы компании кардинально снижали сложность, сроки и стоимость импортозамещения в инфраструктуре баз данных 📉
Организации теперь могут проводить перенос данных и хранимой логики на российскую СУБД с сохранением существующих бизнес-процессов и с минимальными операционными рисками.
Это стало возможным благодаря обновлению "Полиглот" 🗣
Оно обеспечивает исполнение запросов, написанных на диалектах SQL ведущих зарубежных СУБД: Oracle, Microsoft SQL Server и PostgreSQL.
Подробно об этом расскажет спикер Диасофт на вебинаре 25 ноября.
🔗 Регистрируйтесь по ссылке!
#реклама
О рекламодателе
📍Короткий ответ: Да.
Диасофт обновил свою СУБД Digital Q.DataBase, чтобы компании кардинально снижали сложность, сроки и стоимость импортозамещения в инфраструктуре баз данных 📉
Организации теперь могут проводить перенос данных и хранимой логики на российскую СУБД с сохранением существующих бизнес-процессов и с минимальными операционными рисками.
Это стало возможным благодаря обновлению "Полиглот" 🗣
Оно обеспечивает исполнение запросов, написанных на диалектах SQL ведущих зарубежных СУБД: Oracle, Microsoft SQL Server и PostgreSQL.
Подробно об этом расскажет спикер Диасофт на вебинаре 25 ноября.
🔗 Регистрируйтесь по ссылке!
#реклама
О рекламодателе
😁4❤2👍1🔥1
В PL/SQL
Ловит любые ошибки
Если пихать это везде и не пробрасывать ошибку дальше, можно спокойно пропустить неожиданные проблемы
Поэтому компилятор кидает предупреждение PLW-6009
Если в кастомном логгере ты все-таки пробрасываешь ошибку дальше, то используй
чтобы отключить это предупреждение
👉 @SQLPortal
EXCEPTION WHEN OTHERS THEN
Ловит любые ошибки
Если пихать это везде и не пробрасывать ошибку дальше, можно спокойно пропустить неожиданные проблемы
Поэтому компилятор кидает предупреждение PLW-6009
Если в кастомном логгере ты все-таки пробрасываешь ошибку дальше, то используй
PRAGMA SUPPRESSES_WARNING_6009
чтобы отключить это предупреждение
ALTER SESSION SET PLSQL_WARNINGS='ENABLE:(6009)';
CREATE PROCEDURE logging ( err VARCHAR2 ) AS
PRAGMA SUPPRESSES_WARNING_6009(logging);
BEGIN
-- логирование ошибки / повторный RAISE
END;
/
CREATE PROCEDURE do_stuff AS
BEGIN
-- какая-то логика
EXCEPTION
WHEN OTHERS THEN logging('Error details');
END;
/
-- Нет ошибок.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥4❤1
В Postgres есть десятки типов индексов, заточенных под разные типы данных и задачи. В целом их можно разделить на две категории:
По назначению или области применения (что именно индексируем). Здесь мы решаем, какие колонки или данные таблицы индексировать и нужно ли применять функцию к индексируемым значениям. Примеры: индекс по одной колонке, составной (composite), покрывающий (covering), частичный (partial) и функциональный/выражения (functional/expression) индекс.
По внутренней структуре и методу доступа (как индексируем). Эта категория основана на том, как индекс хранит данные под капотом и как СУБД к ним обращается. Примеры: B-tree, hash, GIN, RUM, GiST, SP-GiST, BRIN, HNSW и IVFFlat.
Когда ты выполняешь CREATE INDEX, ты всегда выбираешь тип индекса из первой категории (что индексировать). Выбор структуры (как индексировать) — опционален. Если ничего не указать, Postgres по умолчанию использует B-tree.
👉 @SQLPortal
По назначению или области применения (что именно индексируем). Здесь мы решаем, какие колонки или данные таблицы индексировать и нужно ли применять функцию к индексируемым значениям. Примеры: индекс по одной колонке, составной (composite), покрывающий (covering), частичный (partial) и функциональный/выражения (functional/expression) индекс.
По внутренней структуре и методу доступа (как индексируем). Эта категория основана на том, как индекс хранит данные под капотом и как СУБД к ним обращается. Примеры: B-tree, hash, GIN, RUM, GiST, SP-GiST, BRIN, HNSW и IVFFlat.
Когда ты выполняешь CREATE INDEX, ты всегда выбираешь тип индекса из первой категории (что индексировать). Выбор структуры (как индексировать) — опционален. Если ничего не указать, Postgres по умолчанию использует B-tree.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Postgres UNION vs UNION ALL
Оба оператора объединяют результаты двух или более SELECT запросов в один набор данных.
UNION удаляет дубликаты
UNION ALL оставляет дубликаты
Если ты уверен что дубликатов нет или они тебя не волнуют, UNION ALL будет быстрее, потому что пропускает проверку на повторяющиеся строки.
👉 @SQLPortal
Оба оператора объединяют результаты двух или более SELECT запросов в один набор данных.
UNION удаляет дубликаты
UNION ALL оставляет дубликаты
Если ты уверен что дубликатов нет или они тебя не волнуют, UNION ALL будет быстрее, потому что пропускает проверку на повторяющиеся строки.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3👀2