PostgreSQL *

Привет, Хабр! На связи Марк — ведущий архитектор группы компаний «ГлоуБайт». Сегодня мы немного расширим результаты нагрузочного тестирования из предыдущей статьи «Нагрузочное тестирование 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 человек.

В этой статье я расскажу, что поменялось в проекте за полгода, какие новые возможности появились и какие планы дальше.

Для высоконагруженных систем выбор оптимального метода пагинации становится критически важным для производительности приложений. Данное исследование представляет собой сравнительный анализ трех основных подходов к пагинации в PostgreSQL при работе с таблицей в 15+ миллионов записей. Результаты не просто демонстрируют количественные различия в скорости выполнения запросов, но и раскрывают фундаментальные различия в использовании системных ресурсов, что позволяет принимать архитектурные решения на основе данных, а не предположений.

Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.

В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.

Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.

Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.

Привет, Хабр.

Меня зовут Роман, я основатель Somazone — платформы для сохранения голосовой памяти о близких людях. Пользователь загружает аудиозаписи, мы клонируем голос и создаём AI-агента, с которым можно общаться.

Звучит просто, да?

Два месяца без выходных. Рефакторинги в три часа ночи, когда глаза уже не фокусируются, но ты точно знаешь, что если не починишь сейчас — утром будет хуже. Прод падает в субботу вечером, когда ты наконец-то решил поужинать с семьёй. Баги, которые воспроизводятся только на проде и только у одного пользователя из Владивостока (почему Владивосток? мы так и не поняли). WebSocket-соединения, которые умирают по непонятным причинам. FFmpeg, который выжирает всю память на сервере и роняет всё вокруг.

Это была весёлая поездка. И я хочу поделиться граблями, на которые мы наступили, чтобы вы могли их обойти. Или хотя бы посмеяться над нашими страданиями.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Эффективная пагинация — не просто удобство, а необходимость. Анализ нагрузочного тестирования, метрик системы и планов выполнения показывает, что выбор неправильного метода может замедлить приложение в 15 раз, создавая катастрофическую нагрузку на СУБД. Одни методы работают с молниеносной скоростью, а другие превращаются в «убийц производительности».

Приветствие

Всем привет!
Прошло целых 3 месяца с момента публикации первой статьи. Очень мало свободного времени было для дописывания всех тех фичей, которые я изначально запланировал в плагин. И вот, наконец-то, появилась возможность закончить, когда-то начатый путь, и привести этот плагин к какому-то логическому завершению. В этой статье я хочу поделится своими наработками, мыслями и дальнейшими планами, да и просто оставить это как заметку о работе над пет-проектом.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Исследовать и определить наиболее эффективный SQL-запрос, позволяющий получить информацию для анализа:

• Неполных бронирований

• Билетов без привязки к рейсам

• Рейсов без процедуры посадки

• Статистики по незавершённым операциям

Всем привет! Мы делаем проекты по Zabbix, накопили большую экспертизу и решили сделать переводы нескольких статей, которые нам показались интересными и полезными. Наверняка, будут полезны и вам. Также своим опытом делимся в телеграм-канале zabbix_ru, где вы можете найти полезные материалы и записи наших вебинаров, опубликованных на нашем ютуб-канале (прим. переводчика). Ниже ссылки на предыдущие статьи из цикла.

Миграция с MySQL на PostgreSQL

SELinux: интеграция с Zabbix и другими инструментами

Защита от ложных срабатываний триггеров в Zabbix с использованием функций min/max/avg

Zabbix – автоматизация управления пользователями (JIT)

Zabbix — это надежное решение с открытым исходным кодом для мониторинга ИТ-инфраструктуры, позволяющее отслеживать и анализировать производительность сети, серверов, приложений и других компонентов. По мере роста объема данных эффективное управление временными рядами становится ключевым фактором. Поэтому, начиная с версии 5.0, Zabbix начал поддерживать TimescaleDB — расширение PostgreSQL, оптимизированное для временных рядов. В этой статье рассматриваются преимущества использования TimescaleDB в Zabbix, ключевые таблицы и процесс установки. Подробности под катом.

Стабильная и быстрая работа платформы «1С:Предприятие» — критически важный фактор для бизнеса. Команда Postgres Professional ведёт постоянную работу над совершенствованием ядра СУБД, устраняя архитектурные узкие места, которые проявляются при высоких нагрузках, характерных для 1С.

Недавно мы выпустили Postgres Pro Enterprise 17.6, куда добавили новый пакет улучшений для 1C. 

Статья в формате шпаргалки, для тех кто понимает о чем тут написано и зачем оно надо. Я вчерашний был бы рад, если бы такая статья существовала. Тут максимально кратко изложен мой опыт, без воды и отступлений. По итогу получим полностью готовую инфраструктуру под свои проекты на n8n.

Оптимизировать запрос в вакууме — просто. Но как он поведет себя, когда десятки таких же запросов одновременно борются за ресурсы?

Эксперимент-5 : Условие WHERE