Нет-нет - как раз, самое интересное в рассмотренном кейсе то, что каждый из параллельных потоков занимается созданием своей секции - и секции разные и головная таблица тоже - изначально, мы сразу обозначаем, что с нашей стороны логика правильная - мы не делаем попытки создать одно и то же в конфликтном режиме - для пар/троек и т.д. таблиц со сходными именами получается так, что, из-за ограничения на длину системного имени, "вторая по времени исполнения" транзакция не видит то, что ее "скомпонованное путем урезания" имя для индекса уже занято "первой" транзакцией - возникает конфликт, но это не ошибка Postgres - нужно "разрулить" такие инструкции со стороны пользователя (пользователя СУБД).
Первоначально, распараллеливание - стопроцентное. А в итоге, с использованием нового условия, мы, вынужденно, проблемные пары/тройки и т.д. таблиц объединяем в составные цепочки, для безопасного исполнения, уменьшая т.о. уровень распараллеливания.
Головной процесс создает секционированные таблицы с индексами и составляет перечень параллельных исполнителей (являясь координатором), используя при составлении необходимые условия распределения (только головной процесс читает представление). Каждый исполнитель получает задание на отработку некой цепочки таблиц (в идеальном случае, только одной таблицы, несвязанной ни с какими другими) - при отработке генерируются секции (именно этот процесс представляется длительным и ресурсозатратным и, поэтому, подвергаемым распараллеливанию (например, можно в отдельном потоке создать отдельную таблицу со структурой, аналогичной структуре секционированной таблицы, наполнить ее, и только в конце присоединить ее к головной таблице)). Исполнители ни с кем не взаимодействуют - они пассивны. Но это так в приведенном тестовом примере - конечная реализация может быть разной.
Да, если под очередью понимать последовательное исполнение в рамках одного процесса/потока. Описанные логические зависимости не существуют, они условно вычисляются, с целью выделить из общего числа независимых друг от друга таблиц те группы таблиц, которые сходны по именам. Это дает возможность, при распределении таблиц по параллельным обработчикам, каждую такую группу определить в один поток - цепочка условно зависимых объектов при этом будет обрабатываться строго последовательно (также как и цепочка физически зависимых объектов, которую определяют явно, для корректной обработки), и проблемы не возникнет. Стратегия и реализация распараллеливания могут быть разными - здесь была попытка донести идею, как можно дополнить новым условием саму логику распределения при распараллеливании.
Нет-нет - как раз, самое интересное в рассмотренном кейсе то, что каждый из параллельных потоков занимается созданием своей секции - и секции разные и головная таблица тоже - изначально, мы сразу обозначаем, что с нашей стороны логика правильная - мы не делаем попытки создать одно и то же в конфликтном режиме - для пар/троек и т.д. таблиц со сходными именами получается так, что, из-за ограничения на длину системного имени, "вторая по времени исполнения" транзакция не видит то, что ее "скомпонованное путем урезания" имя для индекса уже занято "первой" транзакцией - возникает конфликт, но это не ошибка Postgres - нужно "разрулить" такие инструкции со стороны пользователя (пользователя СУБД).
Первоначально, распараллеливание - стопроцентное. А в итоге, с использованием нового условия, мы, вынужденно, проблемные пары/тройки и т.д. таблиц объединяем в составные цепочки, для безопасного исполнения, уменьшая т.о. уровень распараллеливания.
Вернее, головной процесс читает представление для распределения, а каждый дочерний - для получения своей цепочки.
Головной процесс создает секционированные таблицы с индексами и составляет перечень параллельных исполнителей (являясь координатором), используя при составлении необходимые условия распределения (только головной процесс читает представление). Каждый исполнитель получает задание на отработку некой цепочки таблиц (в идеальном случае, только одной таблицы, несвязанной ни с какими другими) - при отработке генерируются секции (именно этот процесс представляется длительным и ресурсозатратным и, поэтому, подвергаемым распараллеливанию (например, можно в отдельном потоке создать отдельную таблицу со структурой, аналогичной структуре секционированной таблицы, наполнить ее, и только в конце присоединить ее к головной таблице)). Исполнители ни с кем не взаимодействуют - они пассивны. Но это так в приведенном тестовом примере - конечная реализация может быть разной.
Да, если под очередью понимать последовательное исполнение в рамках одного процесса/потока. Описанные логические зависимости не существуют, они условно вычисляются, с целью выделить из общего числа независимых друг от друга таблиц те группы таблиц, которые сходны по именам. Это дает возможность, при распределении таблиц по параллельным обработчикам, каждую такую группу определить в один поток - цепочка условно зависимых объектов при этом будет обрабатываться строго последовательно (также как и цепочка физически зависимых объектов, которую определяют явно, для корректной обработки), и проблемы не возникнет. Стратегия и реализация распараллеливания могут быть разными - здесь была попытка донести идею, как можно дополнить новым условием саму логику распределения при распараллеливании.