В заключение этого удивительного разговора, свежего как озон после осеннего июньского дождя, оставлю wish-list того, что хотелось бы иметь в GP :
1) Поддержка Oracle хинта /*+ materialize */ - напр., часто в запрос надо прокинуть 2 константных DATE поля для
ограничения between по диапазону дат в join-е с партицированной табл-ой и для этого приходится этот диапазон явно сохранить в отдельную таблицу,
из которой вычитать в переменные, которые передать в запрос

2) Поддержка Oracle хинта /*+ RESULT_CACHE*/, чтобы рез-ты одного и того же запроса можно достать из кэша.

3) Поддержка Oracle опции ALTER TABLE ... SET UNUSED для мгновенного удаления колонки и очистка этого удаленного поля при вакуум

4) Есть удобный drop table if exists, но хорошо бы иметь create table if not exists (в PostgreSQL 17 это сделали)

5) Поправить баг в выдаче расхода RAM в JSON версии плана запроса explain. Сейчас он ограничен int4, значения выше 2^32-1 отображаются <0 (Аренадата уже фиксит )
Если в вас есть, что добавить - you are welcome!!!

#DATA#Фото дня#

Друзья, прошла аномально крупная японская свеча на покупку акций Аренадата ( тикер #DATA ).
Как бы ни развивалась история с обвинением Сергею Мацоцкому( основатель IBS, и, если верить СМИ, держатель крупного пакета акций #DATA )
по даче взятки, безапеляционно верю в компанию, в технологию MPP, продолжаю в нее инвестировать.

Секрет 39 ( Не перегружайте запрос лишними полями )
В продолжение wish-list, пример на проме не заставил себя ждать
Запрос

with cte as (
SELECT 
    a.report_dt,
    a.c1, ... , a.c41
   FROM foo a
     JOIN ( SELECT b.report_dt,
            b.agreement_rk,
            max(b.version_id) AS version_id
           FROM foo b
          GROUP BY b.report_dt, b.agreement_rk) c USING (report_dt, agreement_rk, version_id)
)
select 'total' as nm, '2999-12-31' as report_dt, count(*) from cte
union all
select 'q1' as nm, report_dt, count(*) from cte
where report_dt between '2025-01-01' and '2025-03-31'
group by 2
union all
select 'q2' as nm, report_dt, count(*) from cte
where report_dt between '2025-04-01' and '2025-06-30'
group by 2;

создал спилл 20 TB.

Почему меня зацепил этот запрос ?
По ряду причин.
Если исключить список лишних полей a.c1, ... , a.c41( которые разработчик видимо на автомате скопипастил из кода аксессора, который наш фреймворк использует для доступа к витринам), не влияющих на результат , спилл падает до 3.5 TB:

with cte as (
SELECT 
    a.report_dt
   FROM foo a
     JOIN ( SELECT b.report_dt,
            b.agreement_rk,
            max(b.version_id) AS version_id
           FROM foo b
          GROUP BY b.report_dt, b.agreement_rk) c USING (report_dt, agreement_rk, version_id)
)
<тот же набор сабтоталов из 3х селектов, что в исходном запросе>

Если оставить все поля, но выбрать из cte
либо

select 'q1' as nm, report_dt, count(*)
where report_dt between '2025-01-01' and '2025-03-31'
group by 2

либо

select 'total' as nm, '2999-12-31' as report_dt, count(*)

спилл падает до 2.8 TB и 2.6 TB соотв-но, т.е. с учетом погрешности нашего коллекторра спиллов, он одинаков.

Наверное, если бы была поддержка хинта MATERIALIZE как в Oracle, таких аномалий не было бы.

Действительно, если сохранить cte

with cte as (
SELECT 
    a.report_dt,
   FROM foo a
     JOIN ( SELECT b.report_dt,
            b.agreement_rk,
            max(b.version_id) AS version_id
           FROM foo b
          GROUP BY b.report_dt, b.agreement_rk) c USING (report_dt, agreement_rk)
)

в таблу AO/CO zstd1 (24 млрд туплов), то получим спилл данной операции CTAS 2.3 TB, выборка сабтоталов из которой спила уже не создает.

В исходном же варианте, планы запросов для
вариантов

 
select 'total' as nm, '2999-12-31' as report_dt, count(*) from cte

и

select 'total' as nm, '2999-12-31' as report_dt, count(*) from cte
union all
select 'q1' as nm, report_dt, count(*) from cte
where report_dt between '2025-01-01' and '2025-03-31'
group by 2

разительно отличаются.

Друзья, лето в самом разгаре и для тех кто еще думает у меня 2 хорошие новости. Во первых, несмотря на спад туристов на 70% в Анапе, на других ККК, как-то в Кабардинке и Дивноморском аншлаг, по мазуту норма, вода прогрелась до 25, самое то! А с открытием аэроопорта в Геленджике море стало еще доступнее. Во вторых, если кто-то пресытился морем или горами Кавказа И хочет отдохнуть семьей, компанией до 8 чел, то рекомендую классное, уникальное место на берегу р.Кубань, за качество отвечаю, ссылка ниже.

На заметку
А вы знали, что не каждая транзакция откатывается при ошибке ?
Если pl/pgsql функция абортнулась из-за нехватки места
schema's disk space quota exceeded with name : public
то таблицы, которые были ей созданы не откатываются, а остаются как будто транзакция корректно завершилась.
Note:
Did you know that not every transaction is rolled back on error?
If the pl/pgsql function aborted due to lack of space with error
"schema's disk space quota exceeded with name : public"
then the tables that were created by it are not rolled back, but remain as if the transaction had completed correctly.

На заметку
Если вы трассируете pl/pgsql ф-ю в поисках ее узких мест, скажем неоптимального SQL оператора CTAS, имейте ввиду, что CTAS выполненный в режиме explain analyze
создает таблицу x без статы, что чревато тем, что для больших таблиц ( от 40 млрд строк в моем случае ),

select count(*) from x 

может не выполниться, т.к
выполняется без предагрегации на сегментах.
Note:
If you optimize a pl/pgsql function searching its bottlenecks, say a non-optimal SQL CTAS operator, keep in mind that CTAS executed in Explain-Analyze mode
creates table x without stats, which has consequences, for example for large tables (from 40 billion rows in my case),

select count(*) from x

may not execute, because
it is executed without pre-aggregation on segments.

Секрет 40 (Чем раньше, тем лучше или почему ИИ не лучше джуна)

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

Попросили посмотреть очередь "пациентов":
Симптомы те же у каждого, код работает 1ч и рвет с ошибкой,
Command could not be dispatch to segment entry db <127.0.0.1:5432 pid=154069: server closed the connection unexpectedly
У каждого пациента выполняется один и тот же динамический код с точностью до названия таблицы.

Собственно, сам код банален - получить список уникальных версий в CSV формате:

select string_agg(DISTINCT version_id::text, ',') from x

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

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

select string_agg( t.version_id::text, ',') from
(select DISTINCT version from x) t

Кстати, ИИ на запрос "напиши код для Greenplum, который создает из колонки таблицы список ее уникальных значений в формате csv"
выдал код по первому варианту, т.е. без использования MPP

Тут на хабре GP пытаются опустить, тестируя его в экстремальных условиях https://habr.com/ru/companies/datasapience/articles/941046/, я спорить не буду, единственное вопрос к автору

А как в п. 3 на пустой БД vacuum каталога дал - 25%?

Поздравляю всех с Днём Знаний! Внимание вопрос! Почему в Москве 22°, в Казани 27°( а по ощущениям 33). Города на одной параллели

Что не так с лавочкой в Иннополисе?

Друзья, сегодня у меня был незабываемый День Знаний в Иннополисе. На память, предлагаю повеселиться, включаем фантазию - продолжите фразу в контексте того, чем занимаетесь на работе, а я дам версию со стены предсказаний (где их 365 под QR кодами) в технопарке А.С.Попова,что в Иннополисе : Кто рано встаёт..

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

И вот тут мне не даёт покоя тот факт, что динозавры появились 200 млн назад, а машина Тьюринга в 1936, но какой прогресс уже в развитии ИТ зоопарка, и в части концепций, и в части ДНК, на которых они реализованы

Greenplum: динозавр или рабочая лошадь в 2025

Greenplum - это движок, который долгое время был символом корпоративной аналитики.
В эпоху, когда Hadoop только взлетал и все мечтали о дешёвом "data lake", именно Greenplum давал то, чего так не хватало: SQL, транзакции и ACID.

🏦 В банках и телекоме это был настоящий game changer. Hadoop клал файлы и костылял через Hive без транзакций. Greenplum же позволял писать надёжные аналитические запросы, жить в SQL и быть уверенным в консистентности данных. Именно поэтому десятки проектов в 2010-х поднимались на Greenplum.

Что с ним сейчас
⚙️ Архитектура MPP по-прежнему рабочая;
🖥 Кластеры в проде до сих пор крутятся и обслуживают критичные процессы;
⛔️ Хайпа давно нет, а новые проекты почти не появляются;

Уже даже на data конференции 2 и 3 сорта, не приходит тот самый чел в сером в пиджаке, который рассказывает, как они «подняли хранилище на 200 ТБ и все офигели».😁

В конце 2023 Broadcom (после покупки VMware) фактически заморозила основную open-source ветку. Комьюнити жаловалось на редкие релизы и мёртвые пулл-реквесты, и теперь Greenplum в OSS-смысле выглядит как пациент в коме: вроде жив, но движения нет.

🚀 Modern Data Stack уже уехал
-Lakehouse решили вопрос ACID через Delta, Iceberg, Hudi
-Cloud-first модели с pay-as-you-go съели рынок
-Экосистема вокруг Icebrg, Airflow, Trino даёт гибкость и скорость, которой у Greenplum нет
-Интеграция с ML/LLM? Почти нулевая

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

❓Вопрос на 2025

Greenplum будет жить - потому что миграция с него стоит дорого, а бизнес не любит рисковать. А еще есть arenadata в РФ, которая успела подсадить больших корпов и госы на свой проприетарных GP и отказаться от него теперь очень сложно и дорого.
Но новые проекты? 🤔 Серьёзно, кто сейчас сознательно выберет Greenplum для старта?

Greenplum однажды сделал шаг в будущее раньше Hadoop — дал ACID там, где были только костыли. Но теперь сам остался в прошлом: закрытый OSS, стагнация и потерянный тренд.

У меня только 1 вопрос к автору - а реально есть MPP аналог, такой же удобный, с полным Тьюрингом в режиме компилятора ( а не интерпретатора), интеграцией а-ля PXF с половиной МИРА, партициями, сжатием и все это в одном флаконе?