Добрый день, спасибо за внимание к моей публикации. Я сначала поймал данную проблему на pgPro 16.9 на реальной пром. нагрузке. Дальнейшие эксперименты, в том числе данный синтетический тест проводил на pgPro 16.6. При расследовании изначального инцидента, прочитал, конечно Самохвалова и несколько статей вокруг. Но спасибо за ссылку, эту статью как то упустил. Мой случай немного отличался от рассмотренного (просто много индексов на несекционированной таблице). Можно рассматривать данную статью, как суммаризацию, упрощение и популяризацию того, что уже известно в проф. сообществе :). Наиболее ценным в статье, на мой взгляд, является воспроизводимый test case, бери пробуй, натравливай perf, bpftrace и т.п.
Тезис о том что является общеизвестным - сугубо полемичный. В каждой области конечно есть эксперты, которые хорошо знают внутреннюю механику. Но при переходе от СУБД к СУБД некоторые особенности могут стать сюрпризом.
Добрый день, Спасибо за внимание к моему посту. В данном "синтетическом" случае данная ситуация с VACUUM сыграла мне на руку, мне нужно было как-то "раздуть" таблицу, чтобы воспроизвести ситуацию на ПРОМ системе. Там ситуация даже "одиознее" - соотношение pages/tuples>10, т.е. сплошные дырки, причём там одиночные UPDATE,DELETE,INSERT. Вот и хотелось поисследовать, как мы дошли до жизни такой, ладно VACUUM допустим не может ужать таблицу, т.к. пустые страницы не попадают в конец файла, но почему свободное место в страницах не переиспользуется, это вопрос.
Да можно, коллега на предыдущей работе так делал, когда DBMS_PARALLEL_EXECUTE не устроил по какой-то причине (не помню уже какой). Но всё это уже будет выглядеть посложнее (хотя и не rocket science)
И по первому вопросу - да вы правы корзин немного и совсем неважно как обрабатывать 8 строчек. Для случая большого количества корзин (>100000) данный метод вообще слабо подходит, так как будет нарастать неточность/неравнмерность разбиения.
Отвечу пока на 2ой вопрос. Основная идея была - "как эффективно получить значения границ диапазонов". Генерация WHERE это уже специфика конкретного use case. Вставить условия в стороннее приложение, да ещё и так чтобы storage indexes задействовать в Exa.
Ну не так чтобы совсем уникальные use cases. Например подойдёт если нужно "кормить" какой то процесс для последующей обработки этих данных параллельными потоками.
Так оно так и сделано - в качестве левой границы, берётся правая граница предыдущего диапазона. И обрабатываются особые случаи 1го и последнего диапазона.
Можно, но насколько я помню, это довольно "честное" разбиение, а значит должно быть достаточно медленно на мульти-террабайтных объёмах. Я довольно активно пользовал DBMS_PARALLEL_EXECUTE для параллелизации работы с таблицами содержащими LOB'ы, но здесь мне кажется будет существенно менее оптимально.
на самом деле "ненужные" уже WAL, (ранее произошедшего checkpoint) - вполне себе вычищаются (штатное поведение), т.к. в моём случае checkpoint не происходил ("залипал"), то и WAL все считались "нужными" и соответственно накапливались до переполнения FS.
В моём случае замеры однозначно показали что быстрее. Вся история началась с того, что при построении индексов, один из процессов построения индекса сильно выбился из общего ряда, на не самой большой таблице было более 10 часов. При распараллеливании время уменьшилось почти в 4 раза (4 parallel workers).
Всё конечно зависит от вашего железа и ваших данных.
PS
Из общих принципов выглядит более-менее естественно, больше CPU параллельно исполняет функцию, быстрее всё происходит.
Спасибо большое! А то у меня до 18ой версии никак руки не дойдут.
Добрый день, спасибо за внимание к моей публикации.
Я сначала поймал данную проблему на pgPro 16.9 на реальной пром. нагрузке.
Дальнейшие эксперименты, в том числе данный синтетический тест проводил на pgPro 16.6. При расследовании изначального инцидента, прочитал, конечно Самохвалова и несколько статей вокруг. Но спасибо за ссылку, эту статью как то упустил.
Мой случай немного отличался от рассмотренного (просто много индексов на несекционированной таблице). Можно рассматривать данную статью, как суммаризацию, упрощение и популяризацию того, что уже известно в проф. сообществе :).
Наиболее ценным в статье, на мой взгляд, является воспроизводимый test case, бери пробуй, натравливай perf, bpftrace и т.п.
Тезис о том что является общеизвестным - сугубо полемичный. В каждой области конечно есть эксперты, которые хорошо знают внутреннюю механику. Но при переходе от СУБД к СУБД некоторые особенности могут стать сюрпризом.
Добрый день,
Спасибо за внимание к моему посту. В данном "синтетическом" случае данная ситуация с VACUUM сыграла мне на руку, мне нужно было как-то "раздуть" таблицу, чтобы воспроизвести ситуацию на ПРОМ системе. Там ситуация даже "одиознее" - соотношение pages/tuples>10, т.е. сплошные дырки, причём там одиночные UPDATE,DELETE,INSERT. Вот и хотелось поисследовать, как мы дошли до жизни такой, ладно VACUUM допустим не может ужать таблицу, т.к. пустые страницы не попадают в конец файла, но почему свободное место в страницах не переиспользуется, это вопрос.
Да можно, коллега на предыдущей работе так делал, когда DBMS_PARALLEL_EXECUTE не устроил по какой-то причине (не помню уже какой).
Но всё это уже будет выглядеть посложнее (хотя и не rocket science)
И по первому вопросу - да вы правы корзин немного и совсем неважно как обрабатывать 8 строчек. Для случая большого количества корзин (>100000) данный метод вообще слабо подходит, так как будет нарастать неточность/неравнмерность разбиения.
Отвечу пока на 2ой вопрос. Основная идея была - "как эффективно получить значения границ диапазонов". Генерация WHERE это уже специфика конкретного use case.
Вставить условия в стороннее приложение, да ещё и так чтобы storage indexes задействовать в Exa.
Ну не так чтобы совсем уникальные use cases. Например подойдёт если нужно "кормить" какой то процесс для последующей обработки этих данных параллельными потоками.
Так оно так и сделано - в качестве левой границы, берётся правая граница предыдущего диапазона. И обрабатываются особые случаи 1го и последнего диапазона.
Можно, но насколько я помню, это довольно "честное" разбиение, а значит должно быть достаточно медленно на мульти-террабайтных объёмах. Я довольно активно пользовал DBMS_PARALLEL_EXECUTE для параллелизации работы с таблицами содержащими LOB'ы, но здесь мне кажется будет существенно менее оптимально.
Для бинарных есть ключик -x (вывод в шестнадцатеричном формате )
Например
Frame 8: 140 bytes on wire (1120 bits), 140 bytes captured (1120 bits) on interface any, id 0
Linux cooked capture v1
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 59300, Dst Port: 5432, Seq: 9, Ack: 2, Len: 84
PostgreSQL
Type: Startup message
Length: 84
Protocol major version: 3
Protocol minor version: 0
Parameter name: user
Parameter value: postgres
Parameter name: database
Parameter value: postgres
Parameter name: application_name
Parameter value: psql
Parameter name: client_encoding
Parameter value: UTF8
0000 00 00 03 04 00 06 00 00 00 00 00 00 00 00 08 00 ................
0010 45 00 00 7c 36 77 40 00 40 06 06 03 7f 00 00 01 E..|6w@.@.......
0020 7f 00 00 01 e7 a4 15 38 c7 d5 3f 7b 83 b2 fd 92 .......8..?{....
0030 50 18 02 00 fe 70 00 00 00 00 00 54 00 03 00 00 P....p.....T....
0040 75 73 65 72 00 70 6f 73 74 67 72 65 73 00 64 61 user.postgres.da
0050 74 61 62 61 73 65 00 70 6f 73 74 67 72 65 73 00 tabase.postgres.
0060 61 70 70 6c 69 63 61 74 69 6f 6e 5f 6e 61 6d 65 application_name
0070 00 70 73 71 6c 00 63 6c 69 65 6e 74 5f 65 6e 63 .psql.client_enc
0080 6f 64 69 6e 67 00 55 54 46 38 00 00 oding.UTF8..
Удивительного ничего, просто удобно.
Кстати для Oracle (TNS протокол) тоже есть поддержка
можете попробовать
tshark -i any -f 'tcp port 1521' -d tcp.port==1521,tns -O tns
Да, совершенно с вами согласен, есть вполне реалистичные сценарии, когда параллельность во вред.
на самом деле "ненужные" уже WAL, (ранее произошедшего checkpoint) - вполне себе вычищаются (штатное поведение), т.к. в моём случае checkpoint не происходил ("залипал"), то и WAL все считались "нужными" и соответственно накапливались до переполнения FS.
В моём случае замеры однозначно показали что быстрее.
Вся история началась с того, что при построении индексов, один из процессов построения индекса сильно выбился из общего ряда, на не самой большой таблице было более 10 часов. При распараллеливании время уменьшилось почти в 4 раза (4 parallel workers).
Всё конечно зависит от вашего железа и ваших данных.
PS
Из общих принципов выглядит более-менее естественно, больше CPU параллельно исполняет функцию, быстрее всё происходит.
Статистика показала, что длинные статьи часто не дочитывают, постарался исправиться :)
Потом каждый случай требует проработки и создания синтетического примера, это трудозатраты, которые не всегда получается выполнить одномоментно.
Куда смотреть подсказали ребята из pgPro, большое им за это спасибо.
Потом я решил копнуть немного дальше, ну и поделиться со всеми.
Ссылка в статье, кстати, на код "ваниллы", доступа к pgPro-шному коду не имею ;)
Это by design в ваниле тоже, pgPro в этом отношении (подсистема WAL) не особо отличается, насколько понимаю.
Кроме того что даёт уверенности в консистентности "старых" данных , я преимуществ тоже не вижу.