Что такое pg_partman и что он добавляет к встроенному в Postgres партиционированию?

В Postgres из коробки есть нативное партиционирование:
- Декларативный синтаксис партиционирования в CREATE TABLE
- Автоматическое отсечение партиций (partition pruning), когда запросы исключают нерелевантные партиции
- Прозрачные DML-операции — INSERT/UPDATE/DELETE работают по всем партициям без дополнительной обработки

Что добавляет pg_partman:
- Автоматически создаёт новые партиции по расписанию
- Автоматически удаляет старые партиции по времени или количественным правилам
- Фоновый воркер для выполнения обслуживания без внешних заданий

https://github.com/pgpartman/pg_partman

👉 @SQLPortal

Postgres DOMAINs… лучше, чем CONSTRAINTs?

DOMAIN позволяет задать конкретную проверку значений.

Например, если я хочу убедиться, что все даты рождения больше 1 января 1930 года, а все email-адреса валидны, я могу создать вот так:

CREATE DOMAIN date_of_birth AS date
CHECK (value > '1930-01-01'::date)
;

CREATE DOMAIN valid_email AS text
NOT NULL
CHECK (value ~* '^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+[.][A-Za-z]+$')
;

При создании таблицы достаточно назначить типы date_of_birth и valid_email соответствующим колонкам.

Если в базе есть несколько полей, хранящих дату рождения или email, логика для этих полей будет переиспользована и для дополнительных колонок.

CREATE TABLE person_using_domains
(
    id         INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    firstname  TEXT NOT NULL,
    lastname   TEXT NOT NULL,
    birth_date date_of_birth,
    email      valid_email
);

🤔 DOMAIN vs CHECK CONSTRAINT

Может возникнуть вопрос - зачем использовать DOMAIN, если можно просто навесить CHECK constraint прямо на колонку?
Простой ответ: CHECK constraints не так просто изменять — их нужно удалять и создавать заново.

Кроме того, DOMAIN можно создать на уровне схемы, и если в нескольких таблицах есть колонки с email или датой рождения, можно использовать один DOMAIN для управления всеми этими полями, тем самым централизуя логику.

👉 @SQLPortal

Бросок кубика определяет исход атаки в D&D.

Поэтому знание распределения результатов бросков помогает выбрать правильное действие.

При этом нужно учитывать преимущество , помеху и удачу.

Sean D. Stuber показывает, как сделать это в Oracle SQL.

https://seanstuber.com/2025/07/29/using-sql-to-derive-dice-distributions-in-dnd/

👉 @SQLPortal

Postgres имеет надёжную систему восстановления Point in Time Recovery. Это одна из тех вещей, которые кажутся ненужными… но не стоит заблуждаться. Речь здесь не только о восстановлении - это про более качественные бэкапы и лучшее тестирование миграций.

🔸Что такое PITR?

PITR это как машина времени для вашей базы данных. Если обычные снапшоты это как фотография вашего дома раз в день, то PITR это как камера видеонаблюдения, записывающая каждое изменение. Point in Time Recovery позволяет откатиться к любому моменту времени в базе и создать восстановленную копию именно на этот момент.

🔸WAL

Postgres использует Write-Ahead Log (WAL) для поддержки PITR. Каждое изменение в базе сначала записывается в WAL-файлы, прежде чем попадёт в основные файлы данных. Постоянно архивируя эти WAL-файлы, вы можете воспроизвести любую последовательность изменений и восстановить базу на любой момент времени. Все продвинутые системы бэкапов, которые реализуют PITR — такие как pgBackRest, WAL-G, WAL-E — используют поток WAL для восстановления к конкретной точке времени.

🔸Можно ли восстановиться к абсолютно любому моменту?

Если у вас есть полный базовый бэкап, от которого вы начинаете восстановление, и все WAL-архивы, накопленные с этого момента, вы сможете создать кластер, полностью согласованный с состоянием Postgres на любой выбранный момент времени.

Но у нас маленькая команда и простое приложение...

Красота PITR в том, что это не только для больших приложений и сложных баз. Даже маленькие команды совершают ошибки и хотят обеспечить непрерывную работу для своих пользователей.

🔸PITR полезен не только при сбоя - это ещё и мощный инструмент для тестирования.

Во многих сценариях, например, на Crunchy Bridge, вы можете создать новую версию базы на конкретном моменте времени с помощью концепции форка. Форк создаёт базу с настройками, близкими к текущей, и применяет бэкапы и WAL-файлы на выбранный момент времени. Форки это мощный инструмент для команд разработчиков баз, чтобы тестировать новые версии, изменения приложений и миграции.

👉 @SQLPortal

Часто приходится ковыряться в терминале с CSV или JSON, а стандартные CLI-инструменты всё превращают в кашу.

Tabiew — open-source тулза для комфортного просмотра таблиц прямо в терминале. Есть Vim-стиль управления и SQL-запросы к данным.

Форматы: CSV, Parquet, JSON, Excel и прочее. Можно быстро фильтровать, искать, листать и даже строить графики.

Фишки

🔸Поддержка CSV, Parquet, Arrow, Excel и др.
🔸SQL-фильтрация и анализ прямо в терминале
🔸Vim-подобные хоткеи
🔸Поиск на лету и мульти-табличные операции
🔸Темы Monokai, Nord и др.
🔸Лёгкий, ест даже огромные файлы без лагов

👉 @SQLPortal

Манипуляции с JSON в PL/SQL с использованием объектных типов, добавленных в версии 12.2

JSON_ELEMENT_T
JSON_SCALAR_T
JSON_OBJECT_T
JSON_ARRAY_T

С помощью функций get, put и remove можно получать, добавлять и удалять значения из JSON-объектов и массивов

👉 @SQLPortal

Инструмент для анализа данных на базе AI от Microsoft 🤖

Представляем LLM-powered no-code-инструмент, который преобразует данные и строит крутые визуализации.

Ключевые фичи

🔸Преобразование данных с помощью AI
🔸Интерактивный UI
🔸Ввод на естественном языке

Ссылка на GitHub-репозиторий - https://github.com/microsoft/data-formulator

👉 @SQLPortal

Кто сказал, что на SQL нельзя делать ресерч по рынку?
Этот запрос вытаскивает для каждой FAANG-компании месяц с пиком и месяц с минимумом цены открытия

Задача из Bloomberg SQL

У тебя есть данные по акциям FAANG (Facebook, Amazon, Apple, Netflix, Google) и надо найти месяц и год, когда у каждой бумаги был
- максимальный прайс открытия
- минимальный прайс открытия
при этом даты должны быть в формате Mon-YYYY

Таблица: stock_prices
Хранит дневные котировки
- date — дата в формате типа 01/31/2023
- ticker — тикер, например AAPL
- open, high, low, close — цены открытия, максимума, минимума, закрытия

Разбор запроса

1. CTE month_open
Группируем данные по месяцу и тикеру
Считаем
- max_open — максимальная цена открытия за месяц по тикеру
- min_open — минимальная цена открытия за месяц по тикеру

2. CTE high
Для каждого тикера берём строку с самым высоким значением open
Используем DISTINCT ON (ticker), чтобы оставить только один месяц с максимумом
Результат
- ticker
- high_mth — месяц с пиком открытия
- high_open — сам пик цены открытия

3. CTE low
То же самое, только для минимума
Результат
- ticker
- low_mth — месяц с минимальным открытием
- low_open — минимальная цена открытия

4. JOIN high и low по ticker
На выходе по каждой бумаге месяц+значение максимума и месяц+значение минимума

👉 @SQLPortal

👩‍💻 В сеть вывалилась гигантская куча курсов и книг

Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё!

1402 ГБ — Python
1815 ГБ — Frontend
1515 ГБ — Backend
1300 ГБ — C / C++
694 ГБ — Java
546 ГБ — SQL & БД
411 ГБ — DevOps
898 ГБ — ИБ & Хакинг
212 ГБ — JavaScript
996 ГБ — Kotlin / Swift
173 ГБ — PHP
215 ГБ — GoLang
185 ГБ — Rust
517 ГБ — Linux
115 ГБ — QA / Тестирование
419 ГБ — GameDev
319 ГБ — 1C + Лицензии
617 ГБ — Машинное обучение
687 ГБ — Аналитика Данных
998 ГБ — Дизайн

Подписывайся и не плати за то, что можно получить бесплатно

Я сторонник того, чтобы всегда выбирать инструмент под конкретную задачу

Как бы я ни любил Postgres и MySQL, они заточены под OLTP-нагрузку. А вот когда нужны аналитика или работа с временными рядами — ClickHouse отлично подходит 🤵

На выходных почитал их статью — море интересных инженерных решений

👉 @SQLPortal