Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Parallel Sequential Scan / 22 сообщений из 22, страница 1 из 1
12.11.2015, 08:46
    #39101379
Winnipuh
Winnipuh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
Parallel Sequential Scan is Committed

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

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

Там есть короткий тест на чтение. 743мс против 213мс.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.11.2015, 11:29
    #39101552
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
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
| Ответить | Цитировать | Написать  
12.11.2015, 12:26
    #39101631
jan2ary
jan2ary
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
qwwqхочецца увидеть цей физический девайс хранения, с параллельными головками [на чтение хотя бы].Любая дисковая полка с количеством дисков больше одного :)
Как это в оракле и, скорее всего к тому же идет постгрес: сервер порождает несколько процессов, каждый из которых читает свою часть данных и выдает на гора свой результат родителю, который это все собирает в результирующий набор. Таких конвейеров может быть несколько. В идеале бы еще и читать в обход кеша и даже исключая запись WAL, как бы это ни страшно звучало.
Полезно для хранилищ, агрегирующих запросов, ETL-ей, построений индексов, сортировок...
Насколько я понял, с реализацией Parallel Sequential Scan есть проблемы в коммуникации и синхронизации между порожденными процессами, ну и планировщик тоже надо научить соответствующим навыкам.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.11.2015, 13:43
    #39101793
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
jan2aryqwwqхочецца увидеть цей физический девайс хранения, с параллельными головками [на чтение хотя бы].Любая дисковая полка с количеством дисков больше одного :)
какбе параллелить чтение с полок -- дело драйверов железа, а не субд.
лично мне вот так кааца.

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

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

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

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

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

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

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

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

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

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

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


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


а так я пока на своем вожусь. в сеансе меняю парамсы, запихиваю, сравниваю. тупая какая--то хня, имхо. очень тупайя.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.08.2017, 23:44
    #39511940
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
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
| Ответить | Цитировать | Написать  
29.08.2017, 12:42
    #39512156
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
Maxim Boguk,
понятно,
//но без буферов неспартивна.


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

а растащить агрегат по группам ? не ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.08.2017, 19:47
    #39512430
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
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
| Ответить | Цитировать | Написать  
29.08.2017, 20:28
    #39512441
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
Maxim Boguk,

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

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

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

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

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.08.2017, 18:31
    #39512988
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Parallel Sequential Scan
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
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Parallel Sequential Scan / 22 сообщений из 22, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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