PostgreSQL *

Кэш часто воспринимают как простой способ ускорить систему: положили данные ближе к приложению — получили быстрый ответ. Но на практике главная сложность начинается не с производительности, а с согласованности. Когда данные меняются, кэш может начать «врать»: показывать старые остатки, устаревшие статусы или разные версии одной и той же сущности разным пользователям.

В статье разбираем, почему инвалидация кэша — это архитектурная проблема, как TTL, события, CDC и lease‑подходы влияют на консистентность и когда кэш лучше вообще не использовать.

LEFT JOIN считается одной из самых безопасных конструкций в SQL — пока один фильтр в WHERE тихо не превращает его в INNER JOIN. Ошибка коварная: запрос выглядит абсолютно нормальным, результаты приходят, база не ругается, а часть строк уже исчезла.

В статье разбираем, почему это происходит, как NULL ломает ожидания и чем на самом деле отличаются условия в ON и WHERE.

Один из первых сюрпризов при переходе с MS SQL на PostgreSQL состоит в отсутствии профайлера. Нет ни инструмента, ни аналога. Можно было бы поставить задачу команде разработки, но я решил попробовать поступить иначе, и за сутки, не написав ни строчки кода вручную, собрал работающий MVP с помощью ИИ. Рассказываю, как это было.

Я аквариумист. Однажды мне надоело гуглить совместимость рыб в десяти вкладках и записывать параметры воды в блокнот. За два месяца это вылилось в платформу с маркетплейсом, аукционами, AI-диагностикой и 93 таблицами в PostgreSQL. Рассказываю, что получилось, на чём построено и

В обсуждении под статьями «СУБД Tantor Postgres 18: обзор улучшений для 1С» и «В погоне за APDEX‑ом, или как создать HighLoad на недорогом серверном железе» чрезвычайно уважаемые люди задались вопросом про *_collapse_limit и его отношение к geqo_threshold. В сообществе обсуждали эти параметры в большом топике, в этой статье коротко описано то, к чему там пришли.

Число 20 взялось из поста Роберта Хааса 2009 года по то, можно ли что‑то сделать с параметрами *_collapse_limit в PostgreSQL версии 8.5, которая в то время выходила.

// todo: тут N+1 на invoice — надо переделать через entity graph.

Этот комментарий висел в коде полтора года. Все, кто заходил в файл, его видели. Никто не завёл тикет. В пятницу вечером он сработал — и забрал с собой три пода, 30% запросов на критичной ручке и моё спокойствие на выходные.

Каждый разработчик помнит тот самый момент, когда система, которая только что работала идеально, вдруг начинает вести себя так, будто сошла с ума. Когда дашборд в Grafana показывает что-то страшное, а ты стоишь перед ним с кружкой остывшего кофе и не понимаешь, с чего начать.

На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером.

Спойлер: все выжили. Но стали другими людьми.

Сначала всё выглядело как типичная AI-история успеха.

За пару вечеров LLM помогла превратить Google Sheets для учёта финансов в настоящее приложение. Потом появился backend, sync между устройствами, mobile-first UX, AI-рекомендации, rollback, conflict resolution, миграции, Docker images, golden tests и React-компонент на 10 537 строк.

Оказалось, что AI действительно радикально ускоряет старт разработки. Но production начинается сильно позже демки.

Лучший инструмент 1С эксперта по технологическим вопросам это голова. Подготовка к 1С:Эксперту по технологическим вопросам. Основной курс©

Удар был нанесен тупым предметом, очевидно головой (из милицейского протокола) ©

Из тех кто не собирается стать тимлидом (а возможно и из них тоже) 1С-ники делятся на тех кто собирается идти на экзамен 1С:Эксперт по технологическим вопросам и те кто собирается идти еще раз на экзамен 1С:Эксперт по технологическим вопросам.
Тем из них, кто в очередной раз поклялся за лето/отпуск переделать домашки курса

В SQL самые опасные ошибки часто выглядят как рабочие запросы. Они не падают, не ругаются на синтаксис и не подсвечиваются в IDE — просто возвращают пустоту там, где должны быть данные.

В этой статье разберём классическую ловушку NOT IN: почему один NULL в подзапросе может «отравить» всю выборку, чем IN на самом деле отличается от NOT IN и почему в таких случаях безопаснее писать через NOT EXISTS.

Провести честный тест на 30 000 ВРМ, сжечь 400 тысяч процессорных ядер-часов и доказать, что отечественная связка из RED OS, 1С и Postgres Pro Enterprise способна стабильно держать промышленную нагрузку в 1 Тб — выполнено. Рассказываем историю одного большого нагрузочного тестирования длиною в три месяца

Оператор OUTER JOIN — бич конфигураций 1С на базе PostgreSQL: планировщик пока небогат на оптимизации такого типа соединений. В то же время ORM-фреймворки — и 1С как яркий их представитель — часто генерируют внешние соединения по типовым шаблонам, что открывает возможности для точечной оптимизации.

В этой статье я разбираюсь с одним из таких шаблонов — разрешением полиморфных ссылок: что это за паттерн, откуда он берётся (Rails, Django, Hibernate, Salesforce — не только 1С), насколько он распространён и почему его структурные особенности позволяют существенно ускорить выполнение.

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

SUM() OVER (ORDER BY ...) часто выглядит как очевидный способ посчитать нарастающий итог, пока в данных не появляются одинаковые значения ключа сортировки. В этот момент результат начинает «прыгать», LAST_VALUE возвращает текущую строку, а запрос формально остаётся корректным.

В статье разбираем скрытую причину таких сюрпризов — кадр оконной функции: как база подставляет его по умолчанию, чем ROWS отличается от RANGE и какие детали стоит проверять, чтобы аналитические SQL‑запросы считали именно то, что вы ожидали.

Меня зовут Ирек Агмалов, я DBA-SRE в Ви.Tech - IT-дочке ВсеИнструменты.ру.

Мы обновляли PostgreSQL в кластере Patroni и хотели переключить приложение на новую версию без смены строки подключения и без долгого простоя.

Для роутинга у нас уже использовались consul-dns и Patroni, поэтому вместо замены DSN мы попробовали временно взять переключение трафика на себя через записи в Consul. В статье покажу, как перевели реплику на PostgreSQL 18, сохранили синхронизацию через логическую репликацию и переключили master и replica так, чтобы потом вернуть кластер в нормальный режим работы.

Каждый раз, когда пользователь открывает страницу каталога или дашборд со статистикой, база данных заново считает одно и то же. Запрос к 800 тысячам строк ради одного числа — снова и снова. Расширение pgpro_result_cache в Postgres Pro Enterprise решает эту проблему на уровне СУБД: результат тяжёлого запроса сохраняется в разделяемой памяти и при повторном обращении возвращается за миллисекунду — без сканирования, без нагрузки на процессор, прозрачно для приложения. В этой статье разберём, как это работает, когда кэш действительно полезен и на что нужно обратить внимание при настройке.

Уже совсем немного осталось до выхода релиза СУБД Tantor Postgres 18, и мы хотим наперед рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE, и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли.

В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL‑запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре.

Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

Запутались в многоэтажных SQL‑запросах? Обобщённые табличные выражения (CTE) — тот инструмент, который превращает лапшу из JOIN и подзапросов в читаемый, модульный код.

Разберем на реальных примерах из FinTech и e‑commerce, как разбивать сложную логику на цепочку простых шагов, использовать CTE в UPDATE/DELETE, строить рекурсии для иерархий и избегать ловушек оптимизатора в PostgreSQL.

В логистике проблема часто не в том, что нет данных.

Проблема в том, что данные разбросаны по разным местам.

Одни заявки лежат во внутренней системе, другие — в закрытых кабинетах грузоотправителей, третьи — на тендерных площадках, четвёртые приходят через Excel‑выгрузки, пятые доступны только через веб‑интерфейс. Где‑то есть нормальный HTTP‑обмен, где‑то данные спрятаны за фронтендом, где‑то приходится читать DOM‑таблицу, а где‑то сначала кажется, что всё просто, пока не выясняется, что цена приходит в копейках, маршрут состоит из трёх точек, а тип кузова записан как «тент 20т, верхняя загрузка».

Для менеджера всё это выглядит не как единый рынок грузов, а как набор вкладок в браузере.

Открыть один кабинет. Потом второй. Потом третий. Проверить направление. Сравнить цену. Посмотреть дату. Понять, где реф, где тент, где просто «20 тонн». Не забыть про аукцион, у которого скоро истекает время. Потом всё равно перенести результат в таблицу или открыть внутреннюю панель.

В какой‑то момент стало понятно: нам нужен не ещё один парсер, а единая витрина.

Так появился внутренний агрегатор заявок — условный «Авиасейлз для логистики».

Юнит-тесты в PostgreSQL, как и в других базах данных, не являются обязательными для CI/CD, но они крайне важны и фактически становятся стандартом. С помощью этих юнит-тестов мы уже нашли и исправили много ошибок в функциях на уровне БД, а также сократили загрузку ручных тестировщиков.

Привет, Хабр! В этой статье мы, старший разработчик Анастасия Цацкина и старший инженер-тестировщик Владимир Белинский из IBS, расскажем о нашем опыте внедрения юнит-тестирования на уровне БД.