powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Parallel Sequential Scan
22 сообщений из 22, страница 1 из 1
Parallel Sequential Scan
    #39101379
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Parallel Sequential Scan is Committed

http://rhaas.blogspot.de/2015_11_01_archive.html
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101473
PCContra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
спасибо за новость.

Давайте поподробнее, кто в этом разбирается: что это дает?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101513
jan2ary
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PCContra,

Там есть короткий тест на чтение. 743мс против 213мс.
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101552
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
jan2aryPCContra,

Там есть короткий тест на чтение. 743мс против 213мс.какбе до тех пор, пока неясно, что это алгоритмически -- совершенно [нас много, нас, может быть, рать], в общем -- неважно, что там за миллисекунды.

пока поиск даёт что-то мало (для не носителя) вменяемое.

http://grokbase.com/p/postgresql/pgsql-hackers/0753j91ka9/sequential-scans
http://rhaas.blogspot.fr/2015/03/parallel-sequential-scan-for-postgresql.html

а читать по буквам лень
хочецца увидеть цей физический девайс хранения, с параллельными головками [на чтение хотя бы].

а иначе -- это какие-то мухи в голове, а не параллелизм. (т.е. обрезаем ресурс на процесс, а потом копим процессы, чтобы сложить квоту обрезанного ресурса в ударную псевдопараллельную свинью, вместо того, чтобы выделить процессу сразу вот это вот всё)
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101631
jan2ary
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqхочецца увидеть цей физический девайс хранения, с параллельными головками [на чтение хотя бы].Любая дисковая полка с количеством дисков больше одного :)
Как это в оракле и, скорее всего к тому же идет постгрес: сервер порождает несколько процессов, каждый из которых читает свою часть данных и выдает на гора свой результат родителю, который это все собирает в результирующий набор. Таких конвейеров может быть несколько. В идеале бы еще и читать в обход кеша и даже исключая запись WAL, как бы это ни страшно звучало.
Полезно для хранилищ, агрегирующих запросов, ETL-ей, построений индексов, сортировок...
Насколько я понял, с реализацией Parallel Sequential Scan есть проблемы в коммуникации и синхронизации между порожденными процессами, ну и планировщик тоже надо научить соответствующим навыкам.
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101793
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
jan2aryqwwqхочецца увидеть цей физический девайс хранения, с параллельными головками [на чтение хотя бы].Любая дисковая полка с количеством дисков больше одного :)
какбе параллелить чтение с полок -- дело драйверов железа, а не субд.
лично мне вот так кааца.

ресурс "полка" -- всё равно один. все к нему "в очередь, сукины дети" (с)
-- и какой же, зпт, тут параллелизем ?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101803
jan2ary
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

Ну вот если один процесс не может переварить потенциальную пропускную способность на вводе-выводе, почему бы не отдать ее на растерзание Х процессам? Если очереди нет и полка успевает отдавать все что просят, и успевала бы еще Y раз по столько же?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101858
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqjan2aryпропущено...
Любая дисковая полка с количеством дисков больше одного :)
какбе параллелить чтение с полок -- дело драйверов железа, а не субд.
лично мне вот так кааца.

ресурс "полка" -- всё равно один. все к нему "в очередь, сукины дети" (с)
-- и какой же, зпт, тут параллелизем ?
так разве ПГ с драйверами железа общается? Не с ОС ?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101928
p2.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqкакбе параллелить чтение с полок -- дело драйверов железа, а не субд.Параллелизм бесполезен, когда время обработки меньше времени поступления очередной порции, а цикл взаимодействия между процессом субд и диском ставится в конвеер с нулевыми издержками.
Можно прикинуть. Диск с 100 тысяч iops (4к) дает процессору 2.5ГГц около шести тактов на обработку одного байта. Что там делает secscan? - разбор тупликов с учетом транзакции, всякие LRU в shared buffers ... Полагаю шансы занять параллель у такой конфигурации есть даже, если моя асинхронность равна нулю ©.
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39101942
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p2.qwwqкакбе параллелить чтение с полок -- дело драйверов железа, а не субд.Параллелизм бесполезен, когда время обработки меньше времени поступления очередной порции, а цикл взаимодействия между процессом субд и диском ставится в конвеер с нулевыми издержками.
Можно прикинуть. Диск с 100 тысяч iops (4к) дает процессору 2.5ГГц около шести тактов на обработку одного байта. Что там делает secscan? - разбор тупликов с учетом транзакции, всякие LRU в shared buffers ... Полагаю шансы занять параллель у такой конфигурации есть даже, если моя асинхронность равна нулю ©.
зачем cpu обрабатывать каждый байт?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39102028
p2.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durakзачем cpu обрабатывать каждый байт?Во-первых. Это как придираться к фразе "стоимость перевозки одного пассажира в метро...". Не всех перевозят персональными поездами по каждой станции. В-нулевых. "один" и "каждый" кардинальная подмена понятий. Но! "обрабатывать" все равно придется "все" байты - машинными словами movs'ами или чем еще.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Parallel Sequential Scan
    #39511878
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ALL, parallel вроде как давно в 9.6 запилили. удалось кому его номано попользовать ?

а то что не заталкиваю -- оно либо не берется параллелить, либо результат распараллелинья с гулькин пуп.

специально например делаю

Код: plaintext
1.
2.
3.
селект тяжкий компактный агрегат  груп бай 1 диапазон
юнион олл
селект тяжкий компактный агрегат  груп бай 2 диапазон
-- и не берётся //должно бы не токмо браться за, но и 2--ку отыгрывать

а то камней , бают, под допупа, и чо ?

там какие то подвижки в параллельном планировании проистекают ? или всё рвут неделимый дисковый ресурс на ангельские флаги , хехе
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39511882
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

Работает, вполне себе неплохо.

А какая версия базы стоит?
И какие настройки правились, в особенности `max_worker_processes` и `max_parallel_workers_per_gather`?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39511902
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorovqwwq,

Работает, вполне себе неплохо.


а пару планов с и без можно ?
так, чтобы порвалО, т.с.
для понимания, когда оно что--то может дать. кроме нихера.


а так я пока на своем вожусь. в сеансе меняю парамсы, запихиваю, сравниваю. тупая какая--то хня, имхо. очень тупайя.
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39511940
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

Работает вполне:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
\dt+ job_counters_total
 Schema |        Name        | Type  |  Owner   | Size  | Description
--------+--------------------+-------+----------+-------+-------------
 public | job_counters_total | table | postgres | 11 GB |

set max_parallel_workers_per_gather to 0;
explain analyze select * from job_counters_total where budget_progress>10;
                                                            QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on job_counters_total  (cost=0.00..1535459.10 rows=1947925 width=64) (actual time=0.028..21815.137 rows=1934649 loops=1)
   Filter: (budget_progress > '10'::numeric)
   Rows Removed by Filter: 110108575
 Planning time: 0.178 ms
 Execution time: 22095.783 ms

set max_parallel_workers_per_gather to 2;
explain analyze select * from job_counters_total where budget_progress>10;
                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=100.00..742627.10 rows=1947925 width=64) (actual time=0.236..8020.170 rows=1934655 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on job_counters_total  (cost=0.00..723047.85 rows=811635 width=64) (actual time=0.049..7641.946 rows=644885 loops=3)
         Filter: (budget_progress > '10'::numeric)
         Rows Removed by Filter: 36702897
 Planning time: 0.137 ms
 Execution time: 8335.993 ms

 
 set max_parallel_workers_per_gather to 4;
 explain analyze select * from job_counters_total where budget_progress>10;
                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=100.00..510509.60 rows=1947925 width=64) (actual time=0.254..5113.504 rows=1934659 loops=1)
   Workers Planned: 4
   Workers Launched: 4
   ->  Parallel Seq Scan on job_counters_total  (cost=0.00..490930.35 rows=486981 width=64) (actual time=0.032..4959.423 rows=386932 loops=5)
         Filter: (budget_progress > '10'::numeric)
         Rows Removed by Filter: 22021751
 Planning time: 0.155 ms
 Execution time: 5447.967 ms

set max_parallel_workers_per_gather to 8;
explain analyze select * from job_counters_total where budget_progress>10;
                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=100.00..336421.47 rows=1947925 width=64) (actual time=0.258..3217.341 rows=1934663 loops=1)
   Workers Planned: 8
   Workers Launched: 8
   ->  Parallel Seq Scan on job_counters_total  (cost=0.00..316842.22 rows=243491 width=64) (actual time=0.060..3239.676 rows=214963 loops=9)
         Filter: (budget_progress > '10'::numeric)
         Rows Removed by Filter: 12234317
 Planning time: 0.134 ms
 Execution time: 3640.983 ms

Как то так.
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39512156
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,
понятно,
//но без буферов неспартивна.


т.е. пока оно умеет очень простые вещи параллелить, а именно --фильтр, усекающий данные на почти 2 порядка, который индексно в один поток был бы вероятно быстрее.
а читает оно быстрее в разы, чем фильтрует одним камнем ? (буферсы таки интересны)

а растащить агрегат по группам ? не ?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39512430
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqMaxim Boguk,
понятно,
//но без буферов неспартивна.


т.е. пока оно умеет очень простые вещи параллелить, а именно --фильтр, усекающий данные на почти 2 порядка, который индексно в один поток был бы вероятно быстрее.
а читает оно быстрее в разы, чем фильтрует одним камнем ? (буферсы таки интересны)

а растащить агрегат по группам ? не ?

На IO-bound нагрузке на ПРОСТЫХ seq scan одно ядро у меня где то 400MB/s прожевывает с диска.
3 ядра забивают полосу NVME накопителя (1.2GB/s) на сервере где я тестил.

Когда вы попробуете без индекса в JSONB искать - вам сразу станет ясно зачем оно надо (там просто по CPU очень дорогая операция будет).

>>а растащить агрегат по группам ? не ?
почем не... умеет уже (впрочем тут оно сильно диском лимитируется... in-memory и на 32 ядра раскидываются нормально):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
set max_parallel_workers_per_gather to 0;
explain analyze select employer_id, count(*) from jobs group by employer_id;
                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=7104770.44..7104781.66 rows=1122 width=12) (actual time=342428.504..342429.089 rows=1917 loops=1)
   Group Key: employer_id
   ->  Seq Scan on jobs  (cost=0.00..5464172.36 rows=328119616 width=4) (actual time=0.209..235199.008 rows=333442200 loops=1)
 Planning time: 0.068 ms
 Execution time: 342429.370 ms

set max_parallel_workers_per_gather to 2;
 explain analyze select employer_id, count(*) from jobs group by employer_id;
                                                                        QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=4233982.36..4234010.41 rows=1122 width=12) (actual time=214186.289..214188.928 rows=1917 loops=1)
   Group Key: employer_id
   ->  Sort  (cost=4233982.36..4233987.97 rows=2244 width=12) (actual time=214186.283..214187.174 rows=5167 loops=1)
         Sort Key: employer_id
         Sort Method: quicksort  Memory: 435kB
         ->  Gather  (cost=4233823.80..4233857.46 rows=2244 width=12) (actual time=214181.795..214184.264 rows=5167 loops=1)
               Workers Planned: 2
               Workers Launched: 2
               ->  Partial HashAggregate  (cost=4233723.80..4233735.02 rows=1122 width=12) (actual time=214177.915..214178.533 rows=1722 loops=3)
                     Group Key: employer_id
                     ->  Parallel Seq Scan on jobs  (cost=0.00..3550141.27 rows=136716507 width=4) (actual time=0.192..168485.571 rows=111154117 loops=3)
 Planning time: 1.657 ms
 Execution time: 214189.372 ms


set max_parallel_workers_per_gather to 4;
explain analyze select employer_id, count(*) from jobs group by employer_id;
                                                                       QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=3413853.10..3413897.98 rows=1122 width=12) (actual time=188993.931..188999.031 rows=1917 loops=1)
   Group Key: employer_id
   ->  Sort  (cost=3413853.10..3413864.32 rows=4488 width=12) (actual time=188993.924..188995.841 rows=8373 loops=1)
         Sort Key: employer_id
         Sort Method: quicksort  Memory: 777kB
         ->  Gather  (cost=3413524.76..3413580.86 rows=4488 width=12) (actual time=188986.313..188990.245 rows=8373 loops=1)
               Workers Planned: 4
               Workers Launched: 4
               ->  Partial HashAggregate  (cost=3413424.76..3413435.98 rows=1122 width=12) (actual time=188982.321..188983.136 rows=1675 loops=5)
                     Group Key: employer_id
                     ->  Parallel Seq Scan on jobs  (cost=0.00..3003275.24 rows=82029904 width=4) (actual time=0.128..158947.456 rows=66693015 loops=5)
 Planning time: 1.054 ms
 Execution time: 188999.580 ms

4 worker в диск уже упирается (NVME но даже у него есть лимиты свои... пока не Intel Optane) выйгрыша уже особо нет.

...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39512441
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

понятно,
но тупой аппенд , возникающий в количествах как union all , он параллелить не будет ни за что. пусть обе части тяжелы вычислительно, а результаты их компактны
хотя -- чего, казалось бы, уж проще.
тайна сия велика есть.
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39512465
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqMaxim Boguk,

понятно,
но тупой аппенд , возникающий в количествах как union all , он параллелить не будет ни за что. пусть обе части тяжелы вычислительно, а результаты их компактны
хотя -- чего, казалось бы, уж проще.
тайна сия велика есть.

Какие то вещи реализованы. Какие то - нет. Вот и все.
В 10.0 - будет больше всего паралеллится.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39512654
pihel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
может кто растолковать, как вообще возможно распаралелить индексный доступ. Индекс же на самом нижнем уровне представляет из себя связанный список. Или параллелится фильтр данных, полученных из индекса?
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39512661
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pihelможет кто растолковать, как вообще возможно распаралелить индексный доступ. Индекс же на самом нижнем уровне представляет из себя связанный список. Или параллелится фильтр данных, полученных из индекса?

Смотрите в рассылке -hackers и в исходниках. :)
Начиная где то вот отсюда https://commitfest.postgresql.org/11/849/

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Parallel Sequential Scan
    #39512988
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pihel,

Читайте самое первое сообщение в этой ветке: https://www.postgresql.org/message-id/flat/CAA4eK1%2Bzo4O6ak5ew68SB5EZvZ1j2hxb4af3gaQ_h%3DqAg40vWg%40mail.gmail.com#CAA4eK1+zo4O6ak5ew68SB5EZvZ1j2hxb4af3gaQ_h=qAg40vWg@mail.gmail.com]https://www.postgresql.org/message-id/flat/CAA4eK1 zo4O6ak5ew68SB5EZvZ1j2hxb4af3gaQ_h=qAg40vWg@mail.gmail.com#CAA4eK1 zo4O6ak5ew68SB5EZvZ1j2hxb4af3gaQ_h=qAg40vWg@mail.gmail.com

В данный момент Parallel Scan только для btree реализован. Примерно так (вольный перевод):
0. запускается нужное кол-во параллельных работяг (оценка планировщика)
1. первый спускается по дереву индекса до “листов” — связного списка
2. читает блок из связного списка
3. фиксирует адрес следующего блока в связном списке в разделяемой памяти
4. будит следующего из незянятых работяг и начинает процессить содержимое блока (отдавать записи)
5. “следующий” работяга повторяет аглоритм с пункта #2
...
Рейтинг: 0 / 0
22 сообщений из 22, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Parallel Sequential Scan
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]