PostgreSQL *

- Что вы ожидаете от Greenplum 7?
- Postgres 12!

Если бы мы проводили опрос наших заказчиков, ответ на данный вопрос прозвучал бы именно так.

Как известно, Greenplum является одним из многочисленных форков Postgres, кодовая база которого наконец-то догнала ещё пока поддерживаемую версию Postgres (отмечу, что последний релиз Postgres 12 состоится в ноябре текущего года).

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

Привет, Хабр! Я Владимир Хаймин, эксперт по системам управления базами данных PostgreSQL в ВТБ. В последнее время одним из наиболее распространенных способов миграции стала миграция при помощи свободного инструмента ora2pg. Однако многие отмечают его крайне низкую производительность, особенно если речь идет о базах Oracle размером под 1Тб и выше. Как ускорить миграцию и сократить время простоя при переносе проектов при помощи только oracle_fdw, либо в сочетании с ora2pg расскажу далее.

Спрос на российские СУБД ожидаемо вырос за последние три года.  В этом нет великого предвидения: такова жизнь и так сегодня работает «геополитика». Но в итоге мы очень рады, что начали разработку Proxima DB еще 5 лет назад. В этой статье я расскажу, чем Proxima DB отличается от PostgreSQL, в чем смысл использования нашей платформы, в каких случаях она будет полезна и какие преимущества она дает в конкретных сферах применения. Мы не будем касаться технических подробностей глубоко, потому что это первая ознакомительная статья, сегодня мы постараемся разобраться, когда Proxima DB может дать существенные преимущества, а когда вам будет достаточно ванильной PostgreSQL. А для тех, кто разглядит преимущества платформы для себя, позже я опубликую целую серию технических статей по Proxima DB.

Обычно, обновлением статистик таблиц PostgreSQL занимается демон AUTOVACUUM. Однако, после кардинальных изменений в таблице, к которой сразу же требуется обращаться в последующих запросах к БД, рекомендуется явно обновить статистики этой таблицы явным запуском ANALYZE <имя таблицы>. Команда ANALYZE в PostgreSQL доступна только владельцу таблицы, владельцу базы данных и суперпользователю. При этом иногда возникает необходимость предоставить возможность явного обновления статистик обычному пользователю, не являющемуся владельцем таблицы.

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

Джонатан Кац (Jonathan Katz) пишет:

PostgreSQL 17 Beta 1 запланирована на 23 мая. Пожалуйста, продолжайте тяжёлую работу по закрытию недоделанных пунктов (open items), все поправки намечено доделать к 18 мая. Всем спасибо! Это очень здорово, что мы подошли к этому этапу!

Release notes уже есть, Брюс Момджан о них:

В этом релизе пунктов, связанных с новшествами (feature count), будет 188. Приятный сюрприз для меня: большое число улучшений в оптимизации. Postgres 17 Beta 1 выйдет на днях, а окончательный релиз Postgres 17 запланирован на сентябрь/октябрь этого года.

PostgreSQL 16.3

А также 15.7, 14.12, 13.15 и 12.19. Ветку 12 больше поддерживать не будут.

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

Хеш-индексы в PostgreSQL — это хороший инструмент для ускорения выполнения запросов.

В основе хеш-индекса лежит хеш-функция. Хеш-функция — это алгоритм, который преобразует входные данные (или ключ) в число фиксированного размера, называемое хеш-значением. В PostgreSQL хеш-функция всегда возвращает значение типа integer, что составляет примерно 4 миллиарда возможных значений.

Поделюсь как начал писать приложение для интернет-магазина на монолите, затем перешёл на микросервисы.

Данная статья является продолжением первой части: "PostgreSQL 16. Организация данных. Часть 1".

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

Последние несколько лет мы в Postgres Professional активно занимаемся разработкой своего решения для горизонтального масштабирования PostgreSQL. Пользователям нужен был простой способ увеличить производительность путем добавления узлов. Традиционно для веба в таких случаях просто брали NoSQL базы или шардировали вручную, позже появились распределенные SQL-решения с поддержкой ACID-транзакций. Тем не менее терялась часть возможностей и достоинств PostgreSQL. Корпоративный рынок тяжелых вертикальных решений также сильно ограничен как ценой, так и доступностью. Поэтому исследованиями в области распределенных СУБД в компании занимались еще с 2017 года, а в 2020 началась работа над коммерческим продуктом. 

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

Вдохновившись прошлогодним опытом, мы продолжили начинание и снова проводим конкурс по SQL на международной олимпиаде «IT-Планета».

Конкурс состоит из трех этапов. Заочный теоретический тест собрал почти 3000 человек, из которых на следующий этап мы отобрали примерно 200. Вопросы для этого этапа были подготовлены моим коллегой, Евгением Давыдовым.

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

Третий — очный — этап пройдет в конце мая; постараюсь не затягивать с отчетом, но пока храню интригующее молчание.

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

PostgreSQL очень популярная СУБД. Её используют во многих проектах, как новички, так и профессионалы. Однако не все понимают, как именно работает данная система и какое у неё внутренне устройство.

Давайте разберемся вместе на основе книги «PostgreSQL 16 изнутри» и официальной документации!

Как реализовать хранение и работу каталога папок в PostgreSQL? Есть большое количество вариантов. Но хочется, чтобы реализация выглядела лаконично, не нарушала прозрачность выполняемых операций, не вызывала блокировок, не требовала большого вовлечения клиента в специфику работы и т.д. Потому сегодня попробуем реализовать хранение древовидных структур и работу с ними без использования триггеров, блокировок, дополнительных таблиц (представлений) и внешних инструментов в SQL.

Всем привет!

Как вы знаете, многие поставщики ПО ушли с российского рынка ввиду введённых санкций и многие компании столкнулись с необходимость заняться импортозамещением в кратчайшие сроки. Не стал исключением и наш заказчик. Целевой системой, на которое было принято решение мигрировать старое хранилище, стал Greenplum (далее GP) от компании Arenadata.

Этой статьей мы запускаем цикл материалов посвященных Greenplum. В рамках цикла мы разберем, как вообще устроен GP и как выглядит его архитектура. Постараемся выделить must have практики при работе с данным продуктом, а также обсудим, как можно спроектировать хранилище на GP, осуществлять мониторинг эффективности работы и многое другое. Данный цикл статей будет полезен как разработчикам БД, так и аналитикам.

Сначала запрос адаптирован для работы в PostgreSQL 15.6.

Затем работа запроса проверена на достаточно объемной иерархии - в качестве источника данных использована структура архива jdk-master.zip из OpenJDK 22

Юбилейная - 10-я - конференция PGConf.Russia опередила юбилей компании (Postgres Professional исполнилось 9 лет). А самая первая - PGConf.Russia 2015 - даже опередила саму компанию: конференция прошла в феврале, а официальный день рождения Postgres Professional 1 апреля 2015.

В этой статье я максимально коротко и просто объясню принцип распознавания, хранения и поиска лиц в базе данных. В качестве примера будет использована библиотека Insightface и база данных PostgreSQL.

Казалось бы, в посгресе и так есть неплохой полнотекстовый поиск (tsvector/tsquery), и вы из коробки можете проиндексировать ваши тексты, а потом поискать по ним. Но на самом деле это не совсем то, что нужно — такой поиск работает лишь по чётким совпадениям слов. Т.е. postgres не догадается, что "кошка гонится за мышью" — это довольно близко к "котёнок охотится на грызуна". Как же победить такую проблему?

TLDR:

1. Преобразовываем наши тексты в наборы чисел (векторы) при помощи API openAI.
2. Сохраняем векторы в базе с помощью pgvector.
3. Легко ищем близкие друг к другу векторы или ищем их по вектору-запросу.
4. Ускоряем индексами.

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