А вы знали, что если в ватс апп сменить язык на болгарский то звонки работают без впн( хак от коллеги, не проверял пока)
😁3👏2
Вопрос 8
А кто знает, можно ли в GP сохранить результат запроса, в двумерный массив, не прибегая к PL/pgSQL
Does anyone know if it's possible to save the query result in a two-dimensional array in GP without using PL/pgSQL?
А кто знает, можно ли в GP сохранить результат запроса, в двумерный массив, не прибегая к PL/pgSQL
Does anyone know if it's possible to save the query result in a two-dimensional array in GP without using PL/pgSQL?
SQL> select regexp_matches('a := 1,b := 1', '(\w+)\s*:=\s*([^,]+)', 'g') as m
m
-----
{a,1}
{b,1}Forwarded from Smartyru
Друзья, выручайте, может у кого то завалялся фильм "Босиком по мостовой" с Швайгером, раздайте, плз
Интересно, в вашем ИТ есть собственный фреймворк для генерации SQL кода в ХД.
Или каждый разработчик A пишет готовый к исполнению код с нуля, даже если он повторяет ту же трасформаацию, написанную другим разработчиком B, пусть и на других таблицах.
Опрос ниже по такому поводу.
I wonder if your IT department has its own framework for generating SQL code in the data warehouse.
Or does each developer A write ready-made code from scratch, even if they're repeating the same transformation written by another developer B, albeit on different tables.
The survey is below
Или каждый разработчик A пишет готовый к исполнению код с нуля, даже если он повторяет ту же трасформаацию, написанную другим разработчиком B, пусть и на других таблицах.
Опрос ниже по такому поводу.
I wonder if your IT department has its own framework for generating SQL code in the data warehouse.
Or does each developer A write ready-made code from scratch, even if they're repeating the same transformation written by another developer B, albeit on different tables.
The survey is below
У вас есть in-house фреймворк для генерации ETL кода в DWH? Do you have an in-house framework for generating ETL code in DWH?
Anonymous Poll
53%
Y
47%
N
Проблема 1 (gprestore issue)
Бывает, требуется восстановить данеые из бэкапа по списку таблиц, но не в чистую БД, а в уже созданные чистые таблицы.
Если это делают не одни руки, а команда, то все может пойти не так гладко, как ожидалось.
Предположим, аналитик допустил ошибку, и передал в список на рестор лишнюю таблицу, или наоборот в БД нет какой-то подготовленной таблицы (или ее партиции) из списка.
Оказывается, в этом случае в 6-ке утилита gprestore рухнет при первой же ошибке.
Да, вы не ослышались, без использования ключа --on-error-continue - процесс восстановления прерывается при любой первой возникающей ошибке.
⁉️
Так в чем проблема - включили ключ и погнали ?
⚠️
А в том, что ключ этот имеет неожиданное поведение при работе с бекапсетами собранными с использованием --single-data-file и частичной вычиткой из оных.
Иными словами, если из бэкапа в сотни TB надо восстановить скажем 30% из 1000 таблиц, при каждом падении gprestore будет его перечитывать полностью и это уже проблема, которая может растянуться на часы, дни и т.д..
По хорошему, если бы для каждой таблы в бэкапе знать офсет ее DDL скрипта от начала ( а значит прямой указатель на сами данные, которые по идее
идут сразу после), то не пришлось бы перечитывать файл целиком. Собственно, так и работает gprestore без ключа, но до первого падения.
📌Решение: Согласно анонсу, в 6.29.1 данное недоразумение пофиксили, за что компании Аренадата +1 к карме!
Если кто проверял, дайте шуму, дайте знать!
Бывает, требуется восстановить данеые из бэкапа по списку таблиц, но не в чистую БД, а в уже созданные чистые таблицы.
Если это делают не одни руки, а команда, то все может пойти не так гладко, как ожидалось.
Предположим, аналитик допустил ошибку, и передал в список на рестор лишнюю таблицу, или наоборот в БД нет какой-то подготовленной таблицы (или ее партиции) из списка.
Оказывается, в этом случае в 6-ке утилита gprestore рухнет при первой же ошибке.
Да, вы не ослышались, без использования ключа --on-error-continue - процесс восстановления прерывается при любой первой возникающей ошибке.
⁉️
Так в чем проблема - включили ключ и погнали ?
⚠️
А в том, что ключ этот имеет неожиданное поведение при работе с бекапсетами собранными с использованием --single-data-file и частичной вычиткой из оных.
Иными словами, если из бэкапа в сотни TB надо восстановить скажем 30% из 1000 таблиц, при каждом падении gprestore будет его перечитывать полностью и это уже проблема, которая может растянуться на часы, дни и т.д..
По хорошему, если бы для каждой таблы в бэкапе знать офсет ее DDL скрипта от начала ( а значит прямой указатель на сами данные, которые по идее
идут сразу после), то не пришлось бы перечитывать файл целиком. Собственно, так и работает gprestore без ключа, но до первого падения.
📌Решение: Согласно анонсу, в 6.29.1 данное недоразумение пофиксили, за что компании Аренадата +1 к карме!
Если кто проверял, дайте шуму, дайте знать!
🤡5
#LEGO#фреймворк#парсинг динамического кода
Друзья, сверстал последний пост в уходящем году, а возможно в принципе на канале.
Меня очень занимает, если не вдохновляет, идея создания универсального фреймворка, в котором будут все возможные SQL трансформации, т.к. интуиция подсказывает, что их множество ограничено, хотя и велико.
Вероятно, у многих, кто использует свой in-house фреймворк, основной набор трансформаций T1, T2, ..., Tn реализован на PL/pgSQL
функциях, у каждой из которых есть параметры, задающие входную таблицу(-ы)
С большой вероятностью, из этих лего деталек T(i) вы строите достаточно сложные PL/pgSQL функции F для наполнения целевых витрин,
которые могут быть достаточно емкими по размеру, но построены по модульному принципу, т.е. представлены цепочкой трансформаций.
А если так, то вполне вероятно, что рано или поздно возникнет задача миграции определенной области ХД,
в которых используются F, на новый сервер.
И вот тут, если скажем исходные данные для F лежат в слое RDV, встает вопрос, какие именно таблицы требуются
для переносимого функционала.
Я имею ввиду, что сценарий, когда надо восстановить из бэкапа ряд таблиц RDV, представляющих набор исходных данных для
F, и выкатить поток с F на новом сервере,
чтобы бесшовно переключиться на работу ХД в новом контуре - вполне жизненная задача,
ибо миграция петабайтного ХД за один присест - задача практически невозможная как с технической точки зрения
так и экономически нецелесообразная, обычно такого слона едят по частям.
Ввиду того, что такая потребность в получении списка таблиц возникла у меня, я озаботился и написал
парсер для генерации списка исходных таблиц, которые используются в произвольной функции, построенной на операторах фрейма.
Повторюсь, что концептуально такая функция должна состоять из набора трансформаций T(i), представленных PL/pgSQL функциями с именованными параметрами.
Конкретно в моем случае я ловил пару параметров p_in_schema и p_in_table, задающих входы операторов фреймворка
исключая ad-hoc трансформацию, признаком которой является наличие параметра p_sql_text.
Также, поддержал случай, когда название таблицы в p_in_table параметризовано, т.е. завязано на название переменной,
значение которой объявлено либо в секции F declare, либо в ее основном блоке begin .. end.
Из интересного, я бы отметил, что мой любимый DeepSeek сделал 30% работы, остальное допиливал сам.
Особо пришлось повозиться с 2D массивами, т.к. надежды на то, что в 2D можно добавить 1D массив через array_append не оправдались.
Друзья, сверстал последний пост в уходящем году, а возможно в принципе на канале.
Меня очень занимает, если не вдохновляет, идея создания универсального фреймворка, в котором будут все возможные SQL трансформации, т.к. интуиция подсказывает, что их множество ограничено, хотя и велико.
Вероятно, у многих, кто использует свой in-house фреймворк, основной набор трансформаций T1, T2, ..., Tn реализован на PL/pgSQL
функциях, у каждой из которых есть параметры, задающие входную таблицу(-ы)
С большой вероятностью, из этих лего деталек T(i) вы строите достаточно сложные PL/pgSQL функции F для наполнения целевых витрин,
которые могут быть достаточно емкими по размеру, но построены по модульному принципу, т.е. представлены цепочкой трансформаций.
А если так, то вполне вероятно, что рано или поздно возникнет задача миграции определенной области ХД,
в которых используются F, на новый сервер.
И вот тут, если скажем исходные данные для F лежат в слое RDV, встает вопрос, какие именно таблицы требуются
для переносимого функционала.
Я имею ввиду, что сценарий, когда надо восстановить из бэкапа ряд таблиц RDV, представляющих набор исходных данных для
F, и выкатить поток с F на новом сервере,
чтобы бесшовно переключиться на работу ХД в новом контуре - вполне жизненная задача,
ибо миграция петабайтного ХД за один присест - задача практически невозможная как с технической точки зрения
так и экономически нецелесообразная, обычно такого слона едят по частям.
Ввиду того, что такая потребность в получении списка таблиц возникла у меня, я озаботился и написал
парсер для генерации списка исходных таблиц, которые используются в произвольной функции, построенной на операторах фрейма.
Повторюсь, что концептуально такая функция должна состоять из набора трансформаций T(i), представленных PL/pgSQL функциями с именованными параметрами.
Конкретно в моем случае я ловил пару параметров p_in_schema и p_in_table, задающих входы операторов фреймворка
исключая ad-hoc трансформацию, признаком которой является наличие параметра p_sql_text.
Также, поддержал случай, когда название таблицы в p_in_table параметризовано, т.е. завязано на название переменной,
значение которой объявлено либо в секции F declare, либо в ее основном блоке begin .. end.
Из интересного, я бы отметил, что мой любимый DeepSeek сделал 30% работы, остальное допиливал сам.
Особо пришлось повозиться с 2D массивами, т.к. надежды на то, что в 2D можно добавить 1D массив через array_append не оправдались.
🔥3👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Дорогие друзья! Желаю всем нам в новом году, чтобы ни у кого ничего не заклинило и шло все как по маслу!
😁8👏2
Друзья, 2026 год по восточному календарю — это год Красной Огненной Лошади, который начинается 17 февраля 2026 года и продлится до 5 февраля 2027-го, символизируя энергию, страсть, перемены и стремление к независимости.
Так как среди нас есть любители и мастера по шахматам, давно собирался это сделать - в 9:11 PM (21.11 мск) приглашаю всех, у кого есть аккаунтк на личесс на турнир, код на вход - 777, катнем 7 раундов, чтобы успеть до курантов,
https://lichess.org/swiss/FBQq3KT8
Так как среди нас есть любители и мастера по шахматам, давно собирался это сделать - в 9:11 PM (21.11 мск) приглашаю всех, у кого есть аккаунтк на личесс на турнир, код на вход - 777, катнем 7 раундов, чтобы успеть до курантов,
https://lichess.org/swiss/FBQq3KT8
lichess.org
HappyNewYearGreenplum by Wild Red Horse: Standard 3+2 #FBQq3KT8
1 players compete in the Dec 31, 2025 HappyNewYearGreenplum Swiss tournament organized by Wild Red Horse. Winner is not yet decided.
❤2
На заметку
Параметр gp_resource_group_bypass снимает ограничение на параллельное выполнение запросов в ресурсной группе.
Этот параметр может быть установлен только на уровне сессии, и при включении он позволит запросам обходить ограничение
на параллельное выполнение в РГ и выполняться немедленно.
Note
The gp_resource_group_bypass configuration parameter, enables or disables the resource group concurrency limit.
This parameter may only be set at the session level, and when enabled will allow queries to bypass the CONCURRENCY limit for the resource group and run immediately.
Параметр gp_resource_group_bypass снимает ограничение на параллельное выполнение запросов в ресурсной группе.
Этот параметр может быть установлен только на уровне сессии, и при включении он позволит запросам обходить ограничение
на параллельное выполнение в РГ и выполняться немедленно.
Note
The gp_resource_group_bypass configuration parameter, enables or disables the resource group concurrency limit.
This parameter may only be set at the session level, and when enabled will allow queries to bypass the CONCURRENCY limit for the resource group and run immediately.