Greenplum secrets🎩

Запись в партицированную таблицу P через корневую( insert into P as select from S where ) лочит всю таблицу
или запись в P доступна в параллельной сессии ?
Do you think that writing to partitioned table P via root table locks the whole table for writing?

📌Корректный ответ - N, т.е. вся P не блокируется
Не скрою, сам не поверил, но факты - вещь упрямая

✅Обоснование:
Сразу скажу, что тест проводился на табл-е P (AOCO zstd1) с двухуровневым партицированием,
где по src_cd(text) было 8 парт--й по document_date(date) - 194. Всего 1552 партиции.
В S было 6 млн строк, по 1 млн для каждого src_cd, где document_date - случайная дата в интервале 2000 - 2025 г
2 сессии запущены почти одновременнно вручную в порядке 1,2

Рез-т: секции не блокируются для записи в параллельной сессии, что видно по вложенности интервалов выполнения операции INSERT - интервал 2й сессии вложен в интервал первой сессии

📌The correct answer is N, i.e. the whole P is not blocked
It's incredible, but facts are stubborn things
✅Justification:
I will say right away that the test was conducted on the P table(AOCO zstd1) with two-level partitioning,
where there were 8 partitions with src_cd(text) key and 194 with document_date(date). Total is 1552 partitions
In S there were 6 million rows, 1 million for each src_cd, where document_date is a random date in the range of 2000 - 2025
2 sessions were started almost simultaneously manually in the order 1,2

Result: sections are not blocked for writing in a parallel session, which is evident from the nesting of the intervals for executing the INSERT operation - the interval of the 2nd session is nested in the interval of the first session

🔸Тест с разным src_cd:
сессия 1:
Test with different src_cd:
session 1:

DO $$
BEGIN
raise notice 'bef ins:%', clock_timestamp();
insert into P
select * from S
    where src_cd = 'S0';
raise notice 'aft ins:%', clock_timestamp();
perform pg_sleep(15);
END$$;
bef ins:2025-04-15 20:19:36.138579+00
aft ins:2025-04-15 20:19:41.516063+00
completed in 20 s 438 ms

сессия 2:
session 2:

DO $$
BEGIN
raise notice 'bef ins:%', clock_timestamp();
insert into P
select * from S
    where src_cd = 'S1'
limit 10000;
raise notice 'aft ins:%', clock_timestamp();
END$$;
bef ins:2025-04-15 20:19:37.226968+00
aft ins:2025-04-15 20:19:41.202767+00
completed in 4 s 17 ms

🔸Тест с одинаковым src_cd:
сессия 1:
Test with same src_cd
session 1:

DO $$
BEGIN
raise notice 'bef ins:%', clock_timestamp();
insert into P
select * from S
    where src_cd = 'S0';
raise notice 'aft ins:%', clock_timestamp();
perform pg_sleep(15);
END$$;
bef ins:2025-04-15 20:27:57.471849+00
aft ins:2025-04-15 20:28:02.630457+00
completed in 20 s 218 ms

сессия 2:
session 1:

DO $$
BEGIN
raise notice 'bef ins:%', clock_timestamp();
insert into P
select * from S
    where src_cd = 'S0'
limit 10000;
raise notice 'aft ins:%', clock_timestamp();
END$$;
bef ins:2025-04-15 20:27:59.406034+00
aft ins:2025-04-15 20:28:02.326422+00
completed in 2 s 970 ms

📌Вывод: В обоих случаях insert в 1й сессии не блокирует insert в 2й сессии.
Задержка 15 сек в 1й сессии дает необходимую паузу для начала теста в рамках 2й сессии, а
limit 10000 в сессии 2 сокращает время выполнения insert дабы исключить потенциальную возможность реализации сценария,
когда временные интервалы insert обеих сессий пересекаются так, что 1-я закончилась пока работает 2-я.

👆Интересно отметить:
Если в качестве приемника P использовать таблицу без партиций, она блокируется на запись сессией 1, и сессия 2 ждет завершения операции insert в сессии 1, но не окончания транзакции.
📌Conclusion: In both cases, insert in session 1 does not block insert in session 2
The 15 sec delay in the 1st session gives the necessary pause to start the test within the 2nd session, and the 10000 limit in session 2 reduces the insert execution time in order to eliminate the potential possibility of a scenario where the insert time intervals of both sessions overlap so that the 1st session ends while the 2nd is running.

👆It is interesting to note:
If you use a table without partitions as a receiver, it is locked for writing by session 1, and session 2 waits for the insert operation in session 1 to complete, but not for the transaction to end.

👍2

535 views18:39