PostgreSQL *

Причиной отсутствия роста производительности и распространения спекуляций в строительной отрасли является качество данных, которыми оперируют участники процессов строительства. В чем основная проблема данных в строительстве? В первую очередь, в отсутствии доверия и прозрачности в системах 3D-7D, что ведёт к появлению рисков, связанных с человеческим фактором, и созданию многоуровневой бюрократии в основных бизнес-процессах строительных компаний.

Сегодня при обмене данными между различными 3D-7D системами мы доверяем хранение наших данных корпорациям. Для поддержания своего влияния на строительную отрасль корпорации, которым невыгодна прозрачность и интероперабельность данных, монополизировали хранение и обработку данных. Вследствие этого поставщики основных CAD и ERP решений постоянно повышают цены за пользование своими продуктами, а простые пользователи вынуждены платить “комиссию” на каждом этапе передачи данных в системах 3D-7D: за подключение, импорт, экспорт и работу с данными, которые пользователи сами создали. 

В ожидании PostgreSQL 15

Я уже рассказал об этапах выполнения запросов и о статистике, и о двух основных видах доступа к данным: о последовательном сканировании и об индексном сканировании.

Настал черед способов соединения. В этой статье я кратко напомню, какие бывают логические типы соединений, и расскажу о первом из трех физических способов соединения — о вложенном цикле. Заодно посмотрим и на новую для 14-й версии мемоизацию строк.

Этим летом абитуриентам было жарко, МГУ по проходному баллу почти превратился в ПТУ, а кто-то успешно поступил в вооруженные силы РФ, сам того не желая. Отсутствие автоматизации в 2021 году, способной обработать распределение абитуриентов по учебным заведениям, а так же необходимость написать продолжение предыдущей статьи, описывающей основы теории о Распределенной Авторизации (РА) побудило решить эту детскую задачу автоматизации. Посмотрим, сколько же рпс нам в этом раз отсыпет антилопа.

О простых и продвинутых способах запуска PostgreSQL в Docker: добавляем healthcheck, ставим на мониторинг, настраиваем параметры.

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

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

Всё, что кладёт прод, делает тебя умнее. © программист, положивший прод

Привет! Я — Женя, рубист из Каруны. В этой статье расскажу, как мы получили, на первый взгляд, тривиальную задачу по работе с индексами, набили кучу шишек и пришли к не очень тривиальному и эффективному решению.

Как найти самые "горячие" запросы на вашем PostgreSQL-сервере? Поискать их в логе и проанализировать план или воспользоваться расширением pg_stat_statements.

А если в лог попадает миллион запросов за сутки?.. Тогда любое значение лимита pg_stat_statements.max окажется недостаточно велико, чтобы собрать правдивую статистику. Так давайте собирать эту статистику прямо с планов!

Но для некоторых сервисов СБИС нам в "Тензоре" производительность запросов к базе настолько важна, что auto_explain.log_min_duration приходится выставлять в единицы миллисекунд - и вот они, миллионы планов... Как не потеряться в них?

Привет, меня зовут Денис, в Arenadata я занимаюсь Greenplum — распределённой СУБД с открытым исходным кодом, разработанной на основе PostgreSQL и заточенной под аналитический профиль нагрузки. Моя работа (помимо разработки) заключается в разборе инцидентов, когда в кластерах клиентов происходит что-то непонятное для нашей технической поддержки. Такие истории обычно заканчиваются детальным внутренним разбором произошедшего, рекомендациями для клиентов и внесением правок в код Greenplum (как в наш fork, так и в upstream). Я расскажу вам про один из инцидентов, которым я занимался в последнее время. Хотя этот случай не привел к технически сложным доработкам, он является показательным примером того, как мы исследуем проблемы с Greenplum. Заодно я расскажу о подробностях внутреннего устройства Greenplum и PostgreSQL, которые не описаны в документации.

В предыдущих статьях я рассказал об этапах выполнения запросов и о статистике.

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

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

При реализации некоторых прикладных задач в рамках экосистемы СБИС случается сталкиваться с неочевидными возможностями PostgreSQL, которые позволяют вместо сложной логики создать решение "в один ход".

Сегодня на примере вполне реальной задачи рассмотрим такие возможности оператора INSERT ... ON CONFLICT.

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

Миграция баз данных всегда сопряжена с рисками и простоями для бизнеса. Сегодня я продемонстрирую, насколько легко можно перенести базу данных PostgreSQL в Kubernetes с минимальными простоями. В этом мне поможет дистрибутив Percona для PostgreSQL Operator.

Содержание цикла статей: https://github.com/nomhoi/empire-erp.

Сегодня начнем рассматривать аналитический учет.

В прошлый раз я рассказал об этапах выполнения запросов. Прежде чем переходить к тому, как работают различные узлы плана (способы доступа к данным и методы соединения), надо разобраться с той основой, на которую опирается стоимостной оптимизатор — со статистикой.

Как обычно, я буду приводить примеры из демобазы. В этой статье будет довольно много планов выполнения, но про их составные части я буду рассказывать только в следующих статьях. Здесь же нас в первую очередь будут интересовать оценки количества строк (кардинальности), то есть числа, указанные в верхней строке плана в позиции rows.

Мы в KTS на многих проектах пользуемся услугами managed database от selectel. За этими кластерами нужно следить, и делать это хотелось бы из одной точки. Этой точкой у нас является prometheus, alertmanager и grafana. 

Из коробки у selectel нет prometheus exporter для manage-баз данных. Есть внутренние графики и мониторинг, но использовать их затруднительно. Поэтому мы написали свой selectel-exporter, который использует selectel API.

В статье расскажем, почему решили его написать и расскажем, что он умеет.

В первой части серии статей про работу с адресами по КЛАДР мы научились импортировать данные этого справочника к себе в базу и превращать их во что-то более удобное для дальнейшей работы.

Сегодня же займемся реализацией конкретных прикладных алгоритмов на этой структуре и рассмотрим, как можно реализовать мгновенную помощь пользователю при вводе адреса, используя возможности префиксного поиска в PostgreSQL.

В настоящее время типовые базы данных продакшена состоят не только из одной базы. Как правило, это несколько баз, соединенных между собой потоковой, логической репликацией, BDR, FDW и другими специфическими для приложений способами репликации и распределения данных.

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

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

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

Для начала в этом посте блога описывается, что такое глобальный дедлок и как он обрабатывается в существующем сейчас PostgreSQL. После этого будет рассмотрена обработка дедлока в распределенной среде.

Что такое дедлок?

Для защиты данных, с которыми работает транзакция (или процесс), можно использовать блокировку. Блокировка - это механизм, предотвращающий обновление или удаление целевых данных нежелательным образом. Если другие транзакции хотят воспользоваться блокировкой и при этом вступают в конфликт, транзакция ждет, пока блокировка не будет освобождена, как показано на рисунке 1.

Иван Чувашов, DBA Okko и Southbridge, поделился жизненными кейсами с PostgreSQL, которые помогут решить ваши проблемы.

Разберем случаи из PostgreSQL: запросы в статусе idle in transaction, выключенные контрольные суммы данных, переполнение int4, убивающие базу временные файлы и загрузку CPU.

Привет, Хабр! Начинаю еще один цикл статей об устройстве PostgreSQL, на этот раз о том, как планируются и выполняются запросы.

Предыдущие циклы были посвящены изоляции и многоверсионности, журналированию и блокировкам.

В этом цикле я собираюсь рассмотреть этапы выполнения запросов, статистику, последовательное сканирование, индексное сканирование, соединение вложенным циклом, соединение хешированием, сортировку и соединение слиянием.

Материал перекликается с нашим учебным курсом QPT «Оптимизация запросов», но ограничивается только подробностями внутреннего устройства и не затрагивает оптимизацию как таковую. Кроме того, я ориентируюсь на еще не вышедшую версию PostgreSQL 14. А курс мы тоже скоро обновим (правда, на версию 13; приходится бежать со всех ног, чтобы только оставаться на месте).

Получение несколько десятков параметров запросом в базы oracle, автоматическая разведка (discovery) метрик и наполнение их данными, и все за один запрос к базе