PostgreSQL *

Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 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

Чистые улицы Калифорнии и свободный доступ к передовым технологиям — мечта любого айтишника 90-х. Но он предпочёл вернуться в страну, где ещё ничего не было, и построить своё с нуля.

В подкасте  «В Офисе» я, Ваня Ботанов, автор телеграм-канала «Деплой» вместе с Олегом Бартуновым. Поговорили о том, почему AI не заменит инженера, и зачем сегодня так важно инвестировать в ИТ-образование. Это вторая часть интервью — не только история развития одного из главных российских open source проектов, но и редкий разговор про деньги, принципы и долгосрочное мышление.

— Какое-то время назад начался отток IT-специалистов из России. Как вы к этому относитесь?

— Я не считаю это чем-то критически страшным. В основном уезжают молодые ребята, и для молодежи нормально поехать, посмотреть, как живут в других странах. Многие большие проблемы в мире и в политике возникают из-за того, что люди не путешествуют. Недавно читал статистику: до недавнего времени 98% граждан не имели загранпаспорта. Что они могут думать о других странах, если никогда в них не были? У них нет критического мышления. А те, кто ездят, видят другую жизнь, понимают, как и где живут люди, какие плюсы и минусы, и их гораздо сложнее зомбировать.

— Где, на ваш взгляд, лучше жить?
— Конечно, там, где родился. Мы родились здесь, у нас своя ментальность. Хотя, например, я был 26 раз в Непале, и мне там очень нравится — чувствую себя комфортно. Думаю, это связано с историческими корнями, я как бы — степной кочевник, но подозреваю, что мой народ всё-таки пришёл из гор. А молодежь, которая уехала, посмотрела мир — если создать им условия, они вернутся.