PostgreSQL *

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

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

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

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

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

Привет, друзья!

За свою практику программирования я успел написать множество малых, средних и крупных проектов, преимущественно в формате Telegram-ботов. Моя история началась с популярной на то время версии aiogram 2.24 (тех, кто в теме, поймут), а сейчас я полностью перешел на версию 3.x, о чем нисколько не жалею.

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

Сегодня мы научимся:

Перефразируя древнюю мудрость: все люди делятся на 10 типов: те, кто не знает, зачем нужны резервные копии, и те, кто делает резервные копии.
В данном обзоре я попробую мал-мала расшифровать свою давнюю табличку (внеся в неё некоторое количество изменений):
Обзор наиболее популярных средств для создания резервных копий PostgreSQL.
Ибо не вижу я ни подобных обзоров в информационном поле, ни грамотного, с технической точки зрения, подхода к выбору инструмента вообще, и для создания резервных копий (РК) СУБД PostgreSQL в тех организациях, куда заносит профессиональная деятельность, в частности. Основной аргумент выбора: знания и умения текущего системного администратора. Доводилось встречаться со сменой инструмента по причине того, что новый администратор баз данных не знал и не умел уже использовавшийся продукт. Причём использовался вполне себе достойный, но... (конкретики не будет, по причинам, например, секретным, увы мне).

В PostgreSQL есть довольно интересный функционал - диапазонные типы данных (range). Они весьма удобны в использовании. Для индексирования этих типов данных существует GIST индекс. Однако на практике часто требуется сочетание BTREE индекса с GIST, что реализуется расширением btree_gist. Насколько эффективно удобство, предоставляемое диапазонными типами данных в сочетании с btree_gist мы и разберем в этой статье.

Для ЛЛ - с производительностью при использовании btree_gist будет плохо.

Привет, Хабр. Сегодня я расскажу вам, как развернуть мощную и супер популярную SQL базу данных PostgreSQL. Для решения этой задачи существует множество способов, но я буду говорить о способе разворачивания при помощи Docker контейнера.

Для старта вам необходимо будет обзавестись VPS сервером (виртуальным или выделенным) с линуксом. Я обычно предпочитаю Ubunta, так что будем рассматривать на ее примере.

После покупки вам предложат способ входа. Обычно это SSH – значит и мы возьмем его за основу.

Допустим данные для входа это:

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

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

DISCLAIMER: посыл этой статьи не в том, что «PostgreSQL — гавно, не используйте PostgreSQL». Посыл в следующем: «Может быть я чего-то не понимаю в этой жизни? Пожалуйста, объясните, может быть я изменю своё мнение!»

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

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

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

Несмотря на то, что наиболее развитым макроязыком является m4, многие разрабочики его не знают. Поэтому был выбран более простой, но многим знакомый препроцессор C - cpp из состава GCC.

Все дальнейшие примеры верны для Linux с установленными GCC и Perl. К сожалению, Windows под рукой у меня нет, но проблем с установкой там GCC и Perl возникнуть не должно.

В данной статье будет рассмотрен подход к автоматизированному созданию карт с использованием следующего технологического стека: QGIS, PostgreSQL, Django, Leaflet. Идея родилась ввиду необходимости быстрого создания интерактивных карт из уже созданных проектов в QGIS. Хочу сразу оговорится что проекты создаются без использования локальных слоев, а исключительно с использование БД для их хранения.

Иногда типичная IT-инфраструктура крупной компании выгляд так: PostgreSQL для аналитики, и Oracle для корпоративных данных, и MySQL для каких-нибудь микросервисов. В таких условиях взаимодействие между различными системами становится настоящим мастхевом. И тут может помочь герой нашей статьи - dblink.

dblink позволяет нам безболезненно дергать данные из одной базы в другую, будь то PostgreSQL или что-то вроде Oracle или MySQL.

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

Объединяя их можно создать мощную систему, способную обрабатывать и анализировать огромные объемы данных.

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

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

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

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

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

Мы — команда Рег.ру, направление облачных сервисов, — однажды решили создать сервис управляемых баз данных, он же DBaaS. Раскрываем технические аспекты DBaaS: на каких технологиях основана услуга, какие инструменты использованы, с какими трудностями мы столкнулись при создании и запуске в продакшн. Будет интересно!

Джонатан Кац (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 миллиарда возможных значений.

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