Друзья, лето в самом разгаре и для тех кто еще думает у меня 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 с половиной МИРА, партициями, сжатием и все это в одном флаконе?

Решение теста выше: Solution of the test above
Как ни странно, запрос 1 кратно лучше, почти на порядок.
Что интересно, если t1 распилить на 2 отдельные таблицы, то в таком варианте дихотомии имеем в среднем выигрыш ~75% ( см. distinct_bench_single_vs_split.txt, 2 прогона).
Но в случае распила с партициями(что есть более жизненный сценарий, кмк), даже если они используются в запросе 2 явно в виде физических таблиц в плане появляется сортировка,
которая сьедает львиную долю run-time ( см. distinct_bench_single_vs_split_partitioned.txt).
Увы, этот самый external merge появляется даже при отборе уникального сета из одной таблицы-партиции.
⁉️А если взять CTE, на которую накинуть DISTINCT ? - болт, результат(план) тот же.
Ума не приложу, зачем так сделано, но реальность 6-ки пока такова.

Oddly enough, query 1 is significantly better, almost an order of magnitude.
Interestingly, if t1 is split into two separate tables, this dichotomy solution yields an average performance gain of ~75% (see distinct_bench_single_vs_split.txt, two runs).
But if partitions are used (which is a more realistic scenario, in my opinion), even if they are explicitly used in query 2 as physical tables, the plan adds a sort,
which eats up the lion's share of runtime (see distinct_bench_single_vs_split_partitioned.txt).
Unfortunately, this same external merge occurs even when selecting a unique set from a single partition table.
⁉️But what if we use a CTE with DISTINCT? Doesn't matter, the result (plan) is the same.
I can't imagine why this was done, but this is the reality of the v6.

📌Собственно, за пререквизиты брал
Actually, I took it as a prerequisite
t1:
tst_100bln_dk - сет из 100 млрд чисел int4 в диапазоне 1..1 000 000 // a set of 100 billion int4 numbers in the range 1..1,000,000

t2:

create table tst_100bln_dk_part_by_n
    (n int, prt_mod int)
WITH (appendonly=true,orientation=column,compresstype=zstd,compresslevel=1)
distributed by (n)
    partition by list(prt_mod)
(partition p0 values (0),
partition p1 values (1),
default partition other);

-- Заполняем чет/нечет партиции по условию prt_mod = mod(n,2) :
-- Fill the even/odd partition according to the condition prt_mod = mod(n,2):

insert into tst_100bln_dk_part_by_n
    select n, (n & 1)
from tst_100bln_dk

Файлы // Files