Друзья, у кого Telegram Desktop приуныл, используйте https://mtproto.ru/personal.php, я взял сторонний сервер и сразу подцепился. Дуров по красоте сделал.

Вопрос 12.
Таблица foo распределена по id, вы делаете запрос
Table foo is distributed by id, you make a query:

select * from foo where id = 1

и вместо ожидаемых 3 строк получаете 1.
При этом, при join-е таблицы с другими таблицами с этим же фильтром, все 3 строки из foo GP отдает корректно.
Как такое возможно ?
And instead of the expected 3 rows, you get 1.
However, when joining the table with other tables using the same filter, GP returns all 3 rows from foo correctly.
How is this possible?

Ответ
Ближе всех был @AndyDira
Для foo имеет место рассинхрон логического и физического распределения данных.
Если у вас был expand кластера, и вы не сделали реорганайз таблицы, такое возможно.
Как это проверить ?
Если в запрос добавить функцию на поле дистрибуции, то он вернет все данные
__@AndyDira was the closest.
For foo, the logical and physical data distributions are out of sync.
If you had an expand cluster and didn't reorganize the table, this is possible.
How can we check this?
If I add a function to the distribution field in the query, it will return all the data.

select * from foo where id + 0 = 1

а все такие кейсы можно найти, исхитрившись:
__and all such cases can be found by using some tricks:

select id+0
from foo
group by 1
having max(gp_segment_id)<> min(gp_segment_id)

Решение проблемы :
Переливка в другую таблицу через CTAS не поможет.
Необходимо выполнить явное перераспределение данных ( по тому же ключу ) :
Solution:
Moving the table to another table via CTAS won't help.
You need to explicitly redistribute the data (using the same key):

ALTER TABLE ... SET WITH (REORGANIZE=true)

У меня в итоге только 2 вопроса:
1) А как так могло получиться, если до expand-а все 3 строки лежали на 1 сегменте
2) Почему при join-е с другой таблицей, GPORCA решил просканировать всю таблицу, несмотря на фильтр id = 1,
явно задающий отсечку сегмента.
Ultimately, I only have two questions:
1) How could this happen if, before the expand, all three rows were on the same segment?
2) Why, when joining with another table, did GPORCA decide to scan the entire table, despite the filter id = 1,
explicitly defining a segment cutoff.

Наиболее вероятный ответ на 1й вопрос А как так могло получиться, если до expand-а все 3 строки лежали на 1 сегменте :
После expand только часть партиций партицированной таблы прошла реорганизацию, при этом 3 искомые строки foo находились в разных партах

На заметку (Говорит и показывает Москва)
А вы знали, что если в поле типа timestamptz ( timestamp with time zone )
вставить дату '1900-01-01'::date, то смещение будет не +03:00, а UTC+02:30:17, для '1917-01-01' - результат уже +02:31:19,
а для '1917-12-01' смещение аж +03:31:19

set timezone = 'Europe/Moscow'

select ('1900-01-01'::date)::timestamptz
union
select ('1917-01-01'::date)::timestamptz
union
select ('1917-12-01'::date)::timestamptz
------------------------------------
1900-01-01 00:00:00.000000 +02:30:17
1917-01-01 00:00:00.000000 +02:31:19
1917-12-01 00:00:00.000000 +03:31:19

WTF ?
Дело в использовании исторических данных часовых поясов (база IANA/Olson).
До введения стандартизированных часовых поясов (примерно 1880–1920 гг.) время мск часто исчислялось по местному солнечному времени обсерватории Москвы,
что создает дробные смещения (минуты и секунды) относительно UTC, отличающиеся от современных целых часовых зон.

В таймзоне UTC такого нюанса нет.
p.s.
Не думай о секундах свысока!

Moscow Time (MSK) used an offset of UTC+02:30:17 from 1 January 1880 until after the 1917 revolution. This specific offset was based on local solar time at the Moscow Observatory, which was roughly 2 hours, 30 minutes, and 17 seconds ahead of Greenwich Mean Time (GMT).

Блокировки 1 апреля пошли не по плану.

@investorbiz

Друзья, новость класса збс!
Гуру и оракул в мире БД @kostja_osipov и непревзойденный церемонейместер подкаста Кирилл Мокевнин родили топчик на его площадке "Организованное программирование".
Обсудили весь таксопарк: SQL, NoSQL, будущее СУБД, ИИ.
Напомню, у нас был с Костей жаркий подкаст летом 25 г (ссылка постом ниже)

https://youtu.be/_9JhY63Cvtc?si=FeHn0rEBZXlN3_qe

Ссылки на трансляцию на российских площадках:
- vkvideo - https://vkvideo.ru/video-224967259_456239258
- rutube - https://rutube.ru/video/72d2081f06703cd8bbbefb2bbcfac0be/

p.s.
У меня только один вопрос, задам в опросе ниже

В продолжение опроса,
радует, что среди подписчиков есть критически мыслящие @vsbace, заметившие в коментариях , что RAC в список БД в опросе строго говоря не вписывается,
т.к. в части стораджа у RAC и GP ничего общего.

Но именно то самое обстоятельство, что HDD/SSD так стремительно дешевеют,
и мнение @kostja_osipov ( которое он выразил в моем подкасте), что рано или поздно распределенная БД превратится в набор дисков в одном серваке,
куда переедут и сами CPU разнесенных нод, и вызвало мое желание создать опрос.

Oracle RAC своего рода, может быть предвестником такого перехода, т.к. это уже не True Shared Nothing, но все же тяготеет к MPP.

И хоть RAC на 4г опередил GP ( см. справку ниже ), подчеркну, опять же, что задачи у этих БД концептуально несколько разные:

🔸Oracle RAC возник как решение для повышения отказоустойчивости и производительности транзакционных систем (OLTP) на архитектуре Shared Disk.

🔸Greenplum был создан как специализированное решение для аналитики больших данных (OLAP) на архитектуре Shared Nothing, изначально нацеленное на горизонтальное масштабирование.

Если говорить о временных масштабах, которые задействованы в опросе, напомню,
1983 год — это ключевая дата для появления первой коммерческой СУБД класса MPP (Teradata),
в то время как 1976 год ( в лице компании Tandem Computers NonStop systems) важен с точки зрения появления архитектуры Shared Nothing в целом.

Далее дам краткий экскурс в историю 2х БД из опроса, которые большинству из нас скорее весго ближе других в этой парадигме.
Справка:
Oracle RAC vs Greenplum

🔸2001 г.: Первый релиз RAC для Oracle 9i. Обеспечил высокую доступность и масштабируемость для OLTP-систем на общем хранилище .
🔸2003 г.: Компания Greenplum основана Скоттом Яра и Люком Лонергеном .
🔸2005 г.: Релиз первого продукта Greenplum — СУБД Bizgres .
🔸2010 г.: Greenplum поглощена корпорацией EMC, которая намерена сделать его основой своего подразделения Big Data
🔸2012 г.: Greenplum становится частью новой компании Pivotal Software, созданной EMC и VMware
🔸2015 г.: Исходный код Greenplum Database (GPDB) открыт (версия 4.3) под лицензией Apache 2, что дало толчок его развитию как Open Source-проекта
🔸2017 г.: Релиз Greenplum 5.0 Ядро PostgreSQL обновлено с 8.2 до 8.3, начинается ускорение процесса слияния с новыми версиями PG
🔸2019 г.: Релиз Greenplum 6 .0 Ядро PostgreSQL обновлено до версии 9.4, что дало значительный прирост производительности OLTP
🔸2020 г.: Компания VMware выкупает Pivotal. Продукт получает название VMware Tanzu Greenplum
🔸2023 г.: Релиз Greenplum 7 Ядро PostgreSQL обновлено до версии 12. Добавлена поддержка AI-векторов и интеграция с LLM
🔸2024 г.: Закрытие исходного кода Broadcom (владелец VMware с 22 ноября 2023 года) принимает решение закрыть исходный код. Будущие версии будут выходить только в составе проприетарного продукта VMware Tanzu Data Suite

Резюме: Лично я в опросе за последний вариант, и судя по тому, что корифеи кремниевой долины проявляют большой, если не хищный интерес к концепции,
воплощенной в Greenplum, с 2003 по сей день, это говорит о том, что у MPP мало шансов оказаться на обочине цивилизации.

С ДНЁМ ВЕЛИКОЙ ПОБЕДЫ! Светлая, вечная память всем павшим и выжившим 😢

🕯️ 81 год отделяет нас от Победной весны, но память о ней по-прежнему звучит в музыке, письмах и семейных историях.

Делимся клипом на песню «Тучи в голубом» — о времени, которое нельзя забывать, и о мирном небе, которое хочется беречь.

С Днём Победы, РУДН! 💙

До мурашек ! ! !

На заметку В PXF, тип decimal мапится по дефолту в decimal(38,10)

На заметку Пришло время установить на рабочую станцию  psycopg2, чтобы грузить csv в БД пачками  в  Python, а не поштучно в DataGrip, который почему-то удручающе тупит на этой опеоации. И неожиданно,
pip install psycopg2
после установки зависимостей не нашёл Microsoft C++ Build Tools. У нас этого ПО не оказалось в списке разрешенных. Однако, оказалось, что pip умеет установить сразу бинарь, и вам не нужно ставить клиент PostgreSql и прочие библиотеки, если указать ключ :
pip install --binary-only :all: (через двойной дефис)

Вопрос 13 Как заселектить поле таблы, которое имеет символ <ZWNBSP> в названии ( так показано в information_schema.columns), напр. <0xfeff>rn?

На заметку' Второй раз упёрся в то, что в моем Excel нет ф-ии ПОДСЧЁТА числа уникальных в столбце, а советы от гугл absolutely mess. Нашёл выход, недолго думая.
Если скопировать столбец А в B, сдвинув B на 1 строку вниз относительно А, в С вбить формулу А(I) =B(I) в строках, кроме крайних двух( где ячейка А или B пуста ввиду смещения B) , то сумма ячеек С с значением Ложь + 1 даст искомый ответ. Ах, да, A должен быть отсортирован перед тиражированием в B. Полагаю, ГП делает так же при расчёте count distinct?

На заметку Завтра дивидендная отсечка у Аренадата. Просто оставлю тут на память в наше турбулентное время.