В статье речь пойдёт о методике разработки в Postgres, которую можно использовать для лучшей интеграции вашего расширения с базой данных. А конкретно - о том, как реализовать кастомные свойства объектов БД (или custom reloptions), которые можно было бы назначать разным типам объектов БД и таким образом управлять поведением расширения.
Введение: почему запросы вдруг тормозят?
Представьте ситуацию: вчера приложение работало нормально, сегодня получили звонок – «Сайт грузит 10 секунд!». Заглядываете в логи, видите, что SQL-запрос выполняется 8 секунд вместо обычных 0.2 секунды. Но база данных, таблицы – всё то же самое. Что изменилось?
Дело в том, что PostgreSQL Query Planner – оптимизатор запросов – принимает решения на основе статистики. Когда статистика устаревает или таблица растёт в 10 раз, планировщик может выбрать неэффективный план выполнения. Например, вместо быстрого Index Scan он выберет медленный Seq Scan всей таблицы. Это не баг – это следствие неправильной информации о данных.
Статья полезна:
- Новичкам в SQL: разберётесь, как работают запросы
- Разработчикам на Symfony/Doctrine, Go с pgx: увидите интеграцию с вашим кодом
- Опытным DBA: найдёте оптимизации для таблиц в миллионы строк
Не требуется: специального опыта. Нужны базовые знания SQL и доступ к PostgreSQL.
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Я не devops, поэтому хотел получать ответы на человеческом языке в любое время. Ты в дороге, приходит алерт, нужно срочно посмотреть логи или проверить статус сервиса. Достаёшь телефон, открываешь SSH-клиент, набираешь команды...
В итоге, я написал Telegram-бота, который принимает запросы на человеческом языке и выполняет их через Claude Code CLI. Теперь вместо journalctl -u nginx --since "1 hour ago" | grep error я просто пишу в Telegram: «Покажи ошибки nginx за последний час». Выложил в opensource.
В статье расскажу про архитектуру и примеры.
В этой статье мы поделимся некоторыми подробностями работы над новыми функциями Greengage, такими как shrink и expand кластера, улучшение вставки для foreign-таблиц и подготовка к интеграции с Apache Iceberg.
Статья, включая иллюстрацию, сгенерирована нейросетью DeepSeek.
Авторский только промпт:
Проанализируй публикации на Хабре по теме производительности СУБД PostgreSQL за последние полгода . Подготовь отчет о наиболее интересных публикациях и общем интересе читателей Хабра к теме производительности СУБД PostgreSQL.
Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition. Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с.
Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит.
Привет, Хабр!
Мы много работаем с компаниями, которым необходимо использовать отечественное ПО для баз данных. В таких проектах часто уже есть инфраструктура на MS SQL Server, PostgreSQL или Oracle Database. Основной конфликт — требования регуляторов и высокая стоимость миграции логики приложений на другую СУБД.
Мы создали продукт, который нативно понимает диалекты и позволяет работать с существующими базами без переписывания кода. В статье расскажем, как развернуть Digital Q.DataBase для начала работы с базами без долгой и затратной миграции.
Мы создали комплексную систему автоматического развертывания кластеров PostgreSQL, протестировали ее более 150 раз, внедрили у заказчика в изолированной инфраструктуре, и все заработало.
Никакого доступа к рабочей инфраструктуре, никакого интернета, никакого «скопировал — вставил». Даже буфер обмена отключен. Все тестируем у себя, воссоздав полностью среду заказчика. А это уже больше похоже на запуск марсохода.
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
На основе методологии и результатов, представленных в статье "PG_EXPECTO: Анализ влияния размера shared_buffers на производительность СУБД PostgreSQL", можно сформулировать и обосновать следующую гипотезу:
Классическая эмпирическая рекомендация "shared_buffers = 25% от объёма оперативной памяти" не подтверждается строгим экспериментом и может считаться научно необоснованной. Основная причина снижения производительности СУБД PostgreSQL при высоком значении hit ratio (доли чтений из кэша) связана с увеличением нагрузки на процессор (CPU) для управления большим буферным пулом и конкуренцией за доступ к данным в памяти, а не с гипотетическими "накладными расходами" на обслуживание самого shared_buffers.
Производительность СУБД — ключевой фактор , однако спонтанные проверки часто искажают реальную картину. PG_EXPECTO — это не просто набор скриптов, а чёткая методология, превращающая анализ PostgreSQL из хаотичного поиска проблем в структурированный, воспроизводимый эксперимент.
Задача
Используя классическую задачу о влиянии значения параметра shared_buffers на производительность СУБД, подготовить и протестировать общую методологию проведения экспериментов по анализу производительности СУБД PostgerSQL c использованием нейросети для анализа статистических данных, собранных комплексом pg_expecto в ходе нагрузочного тестирования.
Привет, Хабр! На связи Марк — ведущий архитектор группы компаний «ГлоуБайт». Сегодня мы немного расширим результаты нагрузочного тестирования из предыдущей статьи «Нагрузочное тестирование GP6 vs GP7 vs Cloudberry» и поделимся результатами тестирования YMatrix. Сразу оговорюсь, что это дополнение к предыдущей статье, для того, чтобы сформировать понимание сравнимости результатов различных форков GreenPlum, поэтому акцентировать внимание будем только на YMatrix. Детали по методике тестирования и как были получены результаты для GP6, GP7 и Cloudberry 1.6, можно прочитать в предыдущей статье по ссылке выше.
Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 19 версии PostgreSQL — по сути, частичкой вклада нашей компании. Благодаря коммиту Ильи Евдокимова, в PostgreSQL 19 планирование JOIN’ов станет до 16 раз быстрее. Если раньше алгоритм сравнения частых значений (MCV) работал за O(N²), и при target=10k само планирование запроса могло занимать десятки миллисекунд, то теперь вместо квадратичного перебора будет использоваться хеш-таблица, а это снижает сложность до O(N). Изменение особенно оценят те, кто работает с неравномерными данными и поднимает default_statistics_target выше 1000.
Подробный разбор с тестами и графиками — в переводе статьи о нашем патче.
Для понимания меня, наверно нужно знать мой путь разработчика.
Закончен университет Имени Ярослава Мудрого в Великом Новгороде по специальности радиотехника.
Практика в КБ Планета, диплом считыватель R-FID меток. защита на 4, кажется никто не понял с моих слов сути устройства и каков был мой вклад.
первая работа:
2010 год сентябрь трудоустройство в НПК СПП в отдел систем видеорегистрации
мы делали видеорегистраторы полетной информации для Сухих и других крутых КБ
дальше меня после 9ти лет стажа и отсутствия перспектив из-за карьерных косяков закинуло в Diakont в 2020 году мы переехали с женой под рождение сына в Алмазово но это отдельная история...
Началась разработка средств доставки и диагностики бесконтактным методом ЭМА и другими...
Роботы были разные, все внутритрубной диагностики. Самый пик и интерес был робот для Малазийцев в проекте стоимостью в 300+ мультов русских. И даже некоторые из команды побывали в Куала-Лумпур, но не я...
Блокировки в СУБД — основа механизма параллельного доступа к данным, но также и частый симптом проблем в архитектуре или ошибок в логике работы с БД. Когда из-за них запросы зависают, нам требуется разбираться, кто кого и когда заблокировал, то есть поднимать и смотреть историю возникновения блокировок.
Чтобы понять цепочку блокировок, обычно строят их дерево рекурсивными запросами. Но частое выполнение таких запросов может существенно замедлить работу СУБД. В худшем случае можно усугубить проблему, которую мы пытаемся диагностировать.
Меня зовут Александра Кузнецова, я бэкенд-разработчик в СберТехе, в команде Platform V Kintsugi — это графический инструмент для сопровождения, разработки и диагностики СУБД на основе PostgreSQL. Расскажу о том, как мы с коллегами интегрировали сбор данных о блокировках в наш мониторинг сессий. Решение работает в фоне и не нагружает БД. И дерево блокировок можно построить для любого момента в прошлом, даже через несколько дней после инцидента. Начнём.
В мире высоконагруженных баз данных выбор метода пагинации может стать решающим фактором для производительности системы. Эксперимент, проведённый с двумя подходами — классическим ROW_NUMBER и отложенным соединением (Deferred Join) — показал, что даже архитектурно более совершенный метод не гарантирует победы без тонкой настройки СУБД. Исследование раскрывает, как правильная конфигурация памяти PostgreSQL перевесила преимущества Deferred Join и позволила ROW_NUMBER добиться превосходства на параллельной нагрузке .
Что общего у запросов из 1С, конструкции IN (VALUES ...) и безобидного выражения x + 0? Все они способны превратить выполнение запроса из миллисекундного дела в многоминутное ожидание, потому что стандартный планировщик PostgreSQL на них «спотыкается». Разбираем, как расширение pgpro_planner переписывает неудобные куски дерева запросов в дружелюбный вид еще до того, как оптимизатор успеет выбрать неудачный план, и почему некоторые из этих решений уже попали в ванильный PostgreSQL 18.
Исследование сравнило два метода пагинации — ROW_NUMBER() и Deferred Join — под нагрузкой до 22 параллельных сессий. Прогноз нейросети предсказывал преимущество ROW_NUMBER(), но реальные тесты показали обратное: Deferred Join оказался на 29,3% быстрее, создавал на 70% меньше ожиданий и лучше масштабировался. Этот кейс демонстрирует, как теоретические оптимизации могут не учитывать реальные ограничения СУБД: работу с памятью, параллелизм и стоимость операций ввода-вывода.
С момента первого релиза Postgresus прошло 6 месяцев. За это время проект получил 246 коммитов, новые функции, а также ~2.7 звёзд на GitHub и ~40к загрузок из Docker Hub. Сообщество проекта тоже подросло, сейчас в проекте числится 11 контрибьюторов, а группа в Telegram — 85 человек.
В этой статье я расскажу, что поменялось в проекте за полгода, какие новые возможности появились и какие планы дальше.
