PostgreSQL *

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

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

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

Вышел Postgres Pro Enterprise 17, и этот релиз принесёт улучшения в области производительности и масштабирования. Одно из ключевых нововведений — расширение Proxima, объединяющее функции пулера, прокси и балансировщика нагрузки, интегрированное непосредственно в ядро СУБД. Кроме того, разработчиков ждут новые возможности управления очередями сообщений, инструменты оптимизации запросов, средства обеспечения безопасности и функции интеллектуального хранения данных.

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

pgTap – это расширение PostgreSQL для разработки юнит-тестов. Сами тесты, как, собственно, и pgTap, пишутся на plpgSQL, что означает низкий порог вхождения для разработчиков PG.

Уверен, что читатель, по крайней мере, знаком с техникой разработки через тесты. Поэтому не буду пускаться в описание теории юнит-тестирования. Благо литературы на эту тему более чем достаточно. Тем не менее, чтобы быть понятым, приведу некоторые детали ниже.

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

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

В этой части совсем простая идея по одновременному решению систем линейных уравнений "пачками".

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

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

Администраторы баз данных часто ломают голову над тем, чтобы выявить самые «прожорливые» процессы, из-за которых страдает быстродействие систем. В далеком 2017-м DBA (а теперь инженер Postgres Professional) Андрей Зубков тоже задавался этим вопросом, а в результате придумал утилиту pg_profile для PostgreSQL, которая сейчас «проросла» в pgpro_pwr.

В этой статье мы расскажем о стратегическом мониторинге БД и научим выявлять узкие места в ваших БД с помощью наших утилит.

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

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

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

Greengage Database — наш форк Greenplum Database. Основная идея — оставить исходный код открытым и продолжить разработку и совершенствование базы данных. Мы собираемся перенести Greengage Database на более новую версию Postgres, предоставив более богатый набор функций всем пользователям сообщества и нашим клиентам.

Но эта задача сложнее, чем может показаться. Ранее для реализации функций массивно-параллельных вычислений Greenplum Database основная функциональность Postgres была существенно переработана. Таким образом, обновление версии Postgres создавало огромные сложности. Например, переход с Postgres 9 на Postgres 12 потребовал огромных усилий — между мажорными релизами было почти 5 лет разработки.

Имея это в виду, мы начали масштабный рефакторинг ядра Greengage Database. Мы собираемся разделить ядро ​​Postgres и специфичные функции Greengage Database, используя стандартные существующие средства Postgres для расширений.

Привет, Хабр! Слышали о землетрясениях, которые происходят каждый день по всему миру? Как правило, если вы не сейсмолог или не живёте рядом с тектоническим разломом, то вам всё равно. Но информировать людей о реальных катастрофах в их регионе очень важно, покажем пример такой системы оповещения через SMS.

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

Есть такая функция в PostgreSQL — generate_series. На первый взгляд, она кажется скучной. Ну подумаешь, генерирует ряды чисел. Но не тут-то было! Этот инструмент спасает от десятков скучных запросов и сотен часов рутины.

generate_series — это функция PostgreSQL, которая создаёт ряды значений на лету.

В обзоре узнаете, как графический интерфейс PG Back Web значительно облегчает управление резервными копиями PostgreSQL. Мы покажем, как настраивать резервные копии всего за несколько кликов.

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

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

В этой части снова сталкиваемся с вложенным в цикл рекурсивным поиском "в ширину".

Привет! Меня зовут Геннадий, я Oracle и PostgreSQL DBA в компании Uzum. По пути еще иногда занимаюсь NoSQL, люблю автоматизировать информацию из Ansible и визуализировать нужные мне метрики в Grafana. Хочу поделиться дашбордом для Grafana, который отображает историю активных сессий PG с их текущим SQL, отсортированных по группам ожиданий. Он помогает мне искать проблемы производительности PG-баз, и может пригодиться тем, кто администрирует Postgres.

«Как ускорить выполнение запросов к базам данных?» — извечный вопрос админов и пользователей. Казалось бы, раньше всё работало неплохо, но стоило клиентской базе вырасти в пять раз, как всё замедлилось. Знакомая ситуация? В этой статье расскажем, как найти запросы, которые можно ускорить, и оптимизировать их.

Статья подготовлена по материалам выступления на конференции PGCONF.СПБ 2024.

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

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

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

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

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

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

Безумные штуки иногда можно найти в интернете. Листая 2024 JavaScript rising stars (https://risingstars.js.org/2024/en#section-all) обнаружил там удивительного зверя - Postgres скомпилированный через emcc в WASM версию, и допиленный до состояния, когда его можно запустить внутри JS-процесса (браузер/Node.js/Bun/etc).

Как он устроен, как им пользоваться, и, самое главное, зачем? Добро пожаловать под кат :)

У вас есть Postgres, где хранится множество текстовых данных. Вы хотите использовать векторные представления (embeddings), к примеру, от OpenAI/Anthropic, чтобы построить систему рекомендаций, улучшенный поиск или реализовать RAG для работы с LLM. Но при этом ставить расширения (extensions) не хочется, а может, и вовсе нельзя — например, в облачных Managed PostgreSQL зачастую нет нужных прав.

Под катом описание open-source решения pg_auto_embeddings, которое вам поможет.

С 2019 года я занимаюсь разработкой open source инструмента под названием pg-index-health, который позволяет анализировать структуру БД и находить потенциальные проблемы.

Все эти годы pg-index-health эволюционировал и развивался. За 2024 год мне при поддержке нескольких контрибьюторов удалось решить большинство остававшихся «детских болячек» и довести проект до состояния, когда он готов к масштабной экспансии.

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

Выбор SQL-запроса в реляционной СУБД в основном определяется пространством поиска возможных планов и техниками поиска плана в этом пространстве. У каждой СУБД оба этих фактора имеют свои особенности, что объясняет, почему иногда при миграции с одной СУБД на другую можно наблюдать как ускорения, так и провалы во времени выполнения отдельных запросов.

Здесь я привожу четыре случая, когда SQL Server позволяет строить планы запросов значительно более оптимальные, нежели это доступно PostgreSQL используя как более широкое пространство возможных планов, так и более совершенные методы оценок эффективности планов. Эти примеры: использование тредов, расширенная статистика, кэширование промежуточных результатов запроса и внутренняя параметризация. Примеры независимы и все кроме первого содержат скрипт воспроизведения - можно сразу листать на ту часть, которая выглядит интереснее.

Полагаю, знание о таких кейсах может быть полезным. Как минимум уменьшит количество стресса при миграции на PostgreSQL и возможно заинтересует кого-то настолько, чтобы начать свой проект в open-source сообществе разработчиков СУБД.