14500
Присоединяйтесь к нашему каналу и погрузитесь в мир баз данных Связь: @devmangx РКН: https://clck.ru/3H4Wo3
Startup vs Total Cost
PostgreSQL считает для каждой операции два показателя:
Startup Cost — работа до первой строки результата. Для seq scan почти ноль, потому что строки можно отдавать сразу. Для sort - сначала надо отсортировать весь набор, и только потом появятся строки на вывод.
Total Cost — startup плюс выполнение до конца, то есть стоимость получения всех строк.
Пример на базе pagila:
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM film WHERE rental_duration = 5;
Seq Scan on film (cost=0.00..76.50 rows=191 width=390) (actual time=0.013..0.252 rows=191 loops=1)
Filter: (rental_duration = 5)
Rows Removed by Filter: 809
Buffers: shared hit=64
Planning Time: 0.063 ms
Execution Time: 0.274 ms
cost=0.00..76.50 означает:Buffers: shared hit=64 говорит, что запрос прошёл по 64 страницам буферного кеша. На этих страницах и строится стоимость:Чтение страниц: 1.0 × 64 страниц = 64.0
Обработка строк: 0.01 × 1000 строк = 10.0
Проверка фильтра: 0.0025 × 1000 строк = 2.5
Итого: ~76.5
Свежак: Elasticsearch не обязателен. BM25 уже есть в Postgres.
Теперь поиск можно закрывать прямо в базе. Postgres для всего.
Читать
👉 @SQLPortal
sqlit — это TUI в стиле lazygit для работы с SQL в терминале.
Поддерживает больше 10 баз (Postgres, SQLite, Supabase, ClickHouse, DuckDB и другие), есть история запросов, автодополнение и прочие удобства.
https://terminaltrove.com/sqlit/
👉 @SQLPortal
SQL встречается с семантическим поиском 🔥
Обычные базы данных не понимают естественный язык. Векторные базы не умеют точно фильтровать.
Knowledge Base Algebra от MindsDB решает эту проблему. И всё это полностью open-source.
Можно подключить больше 200 источников данных — как структурированных, так и неструктурированных и собрать единую базу знаний, которая объединяет семантический поиск, фильтрацию по метаданным и сложную булеву логику (SQL) в одной системе.
Пользователи просто пишут запросы обычным языком. Всё.
Для примера взяли рекомендательную систему фильмов с базой на 300k+ тайтлов. У части данных чёткие поля (жанр, рейтинг, год), а у большинства сплошной бардак (сюжеты, отзывы, куски текста).
С привычными инструментами вариантов немного:
Писать жёсткие SQL-фильтры и терять смысл
Использовать LLM, которая просто угадывает
С MindsDB можно задавать вопрос на естественном языке. Система сама определяет, где нужен семантический поиск, где фильтры, где логика, и возвращает точный результат.
И главное всё это можно запускать локально, прямо на своей машине.
👉 @SQLPortal
Делаешь ли ты эти типичные ошибки в SQL?
Забываешь про NULL
Обрабатываешь данные в памяти Java
Используешь JDBC-пагинацию для больших выборок
Применяешь агрегатные функции вместо оконных
Лукас Эдер объясняет, как делать правильно — и приводит ещё 7 распространённых ошибок.
👉 @SQLPortal
Интересный факт про vector search: проверка меньшего объёма данных делает поиск быстрее и точнее.
Алгоритм HNSW это основа одних из самых быстрых векторных поисков. Если вы использовали Weaviate или другие векторные базы, вы уже сталкивались с HNSW, это стандартный тип индекса, и не случайно.
HNSW можно представить как многоуровневую транспортную систему для векторов: сверху —> редкие длинные связи для глобальной навигации, средний уровень —> средние связи для регионального поиска, низкий уровень —> плотные связи для всех векторов для точного результата. Поиск начинается сверху, постепенно уточняется на каждом слое и в конце достигает максимальной точности на нижнем уровне. Алгоритм «перепрыгивает» через множество неактуальных данных вместо проверки каждого вектора, что делает его быстрее brute-force методов.
Основные параметры, которые можно настраивать:
• maxConnections —> плотность графа; большее значение повышает точность, но замедляет поиск и требует больше памяти
• ef, efConstruction —> динамический размер списков для поиска и построения графа, влияющий на баланс между скоростью и точностью
HNSW это баланс между скоростью, точностью и расходом памяти; улучшение одного всегда требует компромисса с другими.
Подробнее о настройке HNSW и оптимизации: Weaviate docs
👉 @SQLPortal
Использую Beekeeper Studio больше полугода и это самый удобный и красивый бесплатный менеджер баз данных, с которым мне доводилось работать. Приятен интерфейс, удобные горячие клавиши, интуитивная навигация, а подсветка и подтверждение перед удалением файлов делают работу безопасной.
Бесплатная версия покрывает большинство нужных функций, подписка не нужна. Рекомендую всем попробовать. 😎
GitHub: beekeeper-studio
👉 @SQLPortal
На официальной вики PostgreSQL опубликована статья “Don’t Do This”, где собраны типичные ошибки при работе с базой данных и объясняется, почему их стоит избегать
👉 @SQLPortal
Скрытые возможности PostgreSQL
В материале автор делится пятью возможностями, о которых редко говорят в сообществе PostgreSQL. Среди них — GRANT SELECT, DISTINCT ON, ограничения EXCLUDE и другие интересные приемы.
Читать статью: тык
👉 @SQLPortal
Где разместить базу данных бесплатно
Актуальные бесплатные платформы на сегодня ↓
🟢MongoDB Atlas
MongoDB — 512 МБ, автоматические бэкапы
→ mongodb.com
🟢Neon Tech
PostgreSQL — 500 МБ, 190 часов вычислений
→ neon.tech
🟢FreeDB Tech
MySQL — 25 МБ, максимум 200 подключений
→ freedb.tech
🟢Turso
SQLite — 5 ГБ, до 500 миллионов чтений
→ turso.tech
🟢Upstash
Redis — 256 МБ, 500 000 команд
→ upstash.com
🟢Xata
PostgreSQL — 15 ГБ, безлимитный трафик
→ lite.xata.io
🟢Supabase
PostgreSQL — 500 МБ, 5 ГБ трафика
→ supabase.com
🟢CockroachDB
10 ГБ хранилища, 50 млн запросов
→ cockroachlabs.com
🟢Koyeb
PostgreSQL — 1 ГБ, 5 часов выполнения
→ koyeb.com
👉 @SQLPortal
Совет по Postgres для тестирования расширений:
Можно использовать команду LOAD, чтобы подгрузить общие библиотеки только в рамках текущей сессии, вместо изменения shared_preload_libraries и перезапуска Postgres.
LOAD 'auto_explain';
LOAD 'pg_stat_statements';
Автоматизируйте задачи в Postgres с помощью pg_cron. Этот инструмент позволяет по расписанию запускать простые задачи, например VACUUM или пересборку материализованных представлений.
👉 @SQLPortal
Карен Джекс поделилась свежим материалом о партиционировании в Postgres.
Ранее она выступила с этим докладом на Euroko, а теперь опубликовала подробный блог с разбором примера и практическими рекомендациями по эффективному использованию партиционирования.
https://karenjex.blogspot.com/2025/09/postgres-partitioning-best-practices.html
👉 @SQLPortal
В Postgres 18 появились виртуальные вычисляемые колонки
Если убрать ключевое слово stored в определении, колонка не будет храниться на диске, а будет вычисляться на лету.
Это экономит место и не замедляет записи, но может замедлять чтение, так что использовать стоит с умом.
👉 @SQLPortal
Типы связей в базах данных:
Связи показывают, как данные между собой связаны.
Три основных типа связей:
Один к одному (One-to-One) —> запись в одной таблице связана с одной записью в другой таблице.
Один ко многим (One-to-Many) —> запись в одной таблице связана с несколькими записями в другой таблице.
Многие ко многим (Many-to-Many) —> записи в обеих таблицах могут быть связаны с несколькими записями в другой таблице.
👉 @SQLPortal
Шаги SQL-запроса
Когда выполняется SQL-запрос:
SELECT owner, count(*)
FROM cats
WHERE owner != 3
GROUP BY owner
HAVING count(*) = 2
ORDER BY owner DESC;
PostgreSQL позволяет клонировать базу на 6 ГБ за 212 миллисекунд вместо 67 секунд. Вот как это работает.
Клонирование баз данных полезно в нескольких сценариях:
* тестирование миграций без трогания продакшн-данных
* поднятие свежих копий под каждый прогон тестов
* сброс sandbox-окружения между сессиями
* воспроизводимые снапшоты для отладки
Когда база весит несколько мегабайт, pg_dump вполне справляется. Но когда речь идёт о сотнях гигабайт, «просто сделать копию» превращается в серьёзный узкий момент.
В PostgreSQL система шаблонов была всегда. Каждый CREATE DATABASE тихо клонирует template1 под капотом, и вместо template1 можно использовать любую базу.
В версии 15 появился параметр STRATEGY, и по умолчанию включили WAL_LOG — поблочное копирование через журнал предзаписи (WAL). I/O становится ровнее, но для больших баз это медленнее.
В PostgreSQL 18 появилась опция file_copy_method = clone. На современных файловых системах вроде XFS, ZFS или APFS она использует операцию FICLONE. Вместо копирования байтов файловая система создаёт новые метаданные, которые указывают на те же физические блоки. Обе базы используют одно и то же хранилище, пока вы ничего не меняете.
Всю магию здесь делает файловая система, создавая copy-on-write (CoW) клон файлов.
Когда вы обновляете строку, файловая система запускает copy-on-write только для затронутых страниц. Всё остальное остаётся общим. Клон на 6 ГБ изначально не занимает дополнительного места и растёт только по мере расхождения данных.
Важно помнить один момент: у исходной базы не должно быть активных подключений во время клонирования. Это ограничение PostgreSQL, а не файловой системы.
Довольно круто.
👉 @SQLPortal
Новости: выпущена версия pgFormatter v5.9
pgFormatter пусть и не идеален, но это самый продвинутый форматтер и бьютификатор SQL и PL/pgSQL, заточенный именно под PostgreSQL. Поставляется как CLI-утилита или CGI-программа.
В этом релизе добавили ряд улучшений форматирования и закрыли проблемы, о которых пользователи сообщали с прошлого выпуска.
Основные изменения:
- Исправлено несколько проблем с форматированием JOIN
- Починены отступы после RAISE EXCEPTION ... USING
- Исправлено кривое форматирование CASE с присваиванием переменных
- Добавлен CI-экшен для прогона pgFormatter при каждом commit push
- Исправлена обработка dollar-quoted строк, когда разделитель прилеплен к слову
- Починены отступы у UNION в RETURN QUERY
- Исправлен false negative при детекте ключевых слов QUERY после RETURN
- Добавлен конфиг pre-commit hook
- Исправлено форматирование PL/pgSQL с DECLARE и CASE
- Починено форматирование научной нотации с экспонентами
- Исправлено ошибочное удаление лишних скобок в CREATE POLICY
- Закрыты проблемы с форматированием в PL/pgSQL при использовании DECLARE и CASE
Полный список изменений смотри в release notes
👉 @SQLPortal
onedump позволяет создавать резервные копии и восстанавливать базы данных MySQL и PostgreSQL на локальном компьютере, S3, Google Drive, Dropbox или SFTP с помощью одного инструмента.
https://github.com/liweiyi88/onedump
👉 @SQLPortal
Совет для PostgreSQL: используйте NULLS LAST или NULLS FIRST в ORDER BY, чтобы управлять расположением NULL‑значений в результатах запроса.
Пример:
SELECT order_id, product_name
FROM orders
ORDER BY order_date DESC NULLS FIRST;
В Oracle SQL вы можете вычесть один год из даты с помощью одного из вариантов:
ADD_MONTHS(dt, -12)
- INTERVAL '1' YEAR
ADD_MONTHS → 29 февраля преобразуется в 28 февраля предыдущего годаINTERVAL → 29 февраля преобразуется в 29 февраля предыдущего года → ошибка!
Инструмент командной строки для мониторинга активности сервера PostgreSQL
https://github.com/dalibo/pg_activity
👉 @SQLPortal
На GitHub опубликован бесплатный «6-недельный дорожный план по SQL для Data Science / аналитики»
Проект предлагает по неделе на ключевые темы: основы SQL и SELECT, агрегаты и GROUP BY, JOIN-ы, оконные функции, CTE и подзапросы, а затем — самостоятельные проекты для закрепления навыков 😎
👉 @SQLPortal
Как добиться index-only scan в Postgres?
Используйте covering indexes (покрывающие индексы).
SELECT name, email FROM web_users WHERE id = 123;
CREATE INDEX idx_users_includes
ON web_users (id)
INCLUDE (name, email);
auto_explain.log_min_duration = '1000ms';
Индексируйте скалярные значения в массивах JSON, хранящихся в Oracle Database, с помощью
CREATE MULTIVALUE INDEX ... ON t ( t.json_data.array.<type> )
JSON_EXISTS ( t.json_data, '$.array?(@.<type> == ... )' )
Чтобы кешировать результаты вызовов функций в PL/SQL, объявляйте их с модификаторами:
DETERMINISTIC ⇒ кеширование в пределах одного SQL-выражения
RESULT_CACHE ⇒ кеширование между сессиями
Перед использованием убедитесь, что функции имеют ограниченное количество уникальных входных данных и действительно являются детерминированными.
https://mikesmithers.wordpress.com/2022/10/16/deterministic-and-result_cache-pl-sql-functions/
👉 @SQLPortal
Pro-tip по дизайну БД: Soft Deletes
Soft delete — вместо того чтобы физически удалять строку, мы помечаем её как удалённую (например, deleted_at TIMESTAMP).
Плюсы:
- удобно для undo (отката);
- хранение истории ;
- не ломаются внешние ключи.
Но! 🚬
Если напрямую писать запросы к таблице, половина кода будет забывать исключать «удалённые» строки. В итоге поведение приложения становится непредсказуемым и разъезжается в разных местах.
Решение
Всегда создавай view, которое сразу фильтрует «живые» строки.
CREATE VIEW users_active AS
SELECT * FROM users WHERE deleted_at IS NULL;
Получение значений из первой, N-й и последней строки:
FIRST_VALUE ⇒ первая
NTH_VALUE ⇒ N-я
LAST_VALUE ⇒ последняя
По умолчанию окно заканчивается на текущей строке ⇒
NTH_VALUE(v, N) возвращает NULL для строк до N
LAST_VALUE возвращает последнее значение с тем же sort key, а не из самой последней строки
👉 @SQLPortal
Простое объяснение Primary Key и Foreign Key в SQL:
Primary Key (PK) это уникальный идентификатор записи в таблице. В таблице customers поле customer_id является первичным ключом. Каждому клиенту присваивается уникальный номер, и два клиента не могут иметь одинаковый ID. Sarah Johnson всегда будет клиентом с ID 1001, а если завтра зарегистрируется другая Sarah Johnson, ей дадут другой ID. Это помогает организовать данные и избежать путаницы.
Foreign Key (FK) это связь между таблицами, как мост. В таблице orders поле customer_id является внешним ключом. Здесь он не уникален, потому что один клиент может сделать несколько заказов. Например, Sarah (customer 1001) сделала два заказа — на ноутбук и на клавиатуру. Внешний ключ customer_id в таблице orders ссылается на первичный ключ в таблице customers.
Без внешнего ключа пришлось бы хранить имя и email Сары в каждой записи заказа, что создаёт хаос и занимает лишнее место. Используя FK, данные клиента хранятся один раз в таблице customers, а в таблице orders просто ссылаются на него через ID. Это делает систему чистой, эффективной и масштабируемой.
PK уникально идентифицирует запись, а FK соединяет связанные данные между таблицами.
👉 @SQLPortal
Совет для Postgres: используйте jsonb_pretty, чтобы выводить JSON в удобочитаемом вертикальном виде.
👉 @SQLPortal