សំណួរស្របគ្នានៅក្នុង PostgreSQL

ស៊ីភីយូទំនើបមានស្នូលច្រើន។ អស់រយៈពេលជាច្រើនឆ្នាំ កម្មវិធីបាននឹងកំពុងផ្ញើសំណួរទៅកាន់មូលដ្ឋានទិន្នន័យស្របគ្នា។ ប្រសិនបើវាជាសំណួររបាយការណ៍នៅលើជួរជាច្រើនក្នុងតារាងមួយ វាដំណើរការលឿនជាងនៅពេលប្រើស៊ីភីយូច្រើន ហើយ PostgreSQL អាចធ្វើវាបានតាំងពីកំណែ 9.6។

វាត្រូវចំណាយពេល 3 ឆ្នាំដើម្បីអនុវត្តមុខងារសំណួរស្របគ្នា - យើងត្រូវសរសេរកូដឡើងវិញនៅដំណាក់កាលផ្សេងៗនៃការប្រតិបត្តិសំណួរ។ PostgreSQL 9.6 បានណែនាំហេដ្ឋារចនាសម្ព័ន្ធដើម្បីកែលម្អកូដបន្ថែមទៀត។ នៅក្នុងកំណែជាបន្តបន្ទាប់ ប្រភេទសំណួរផ្សេងទៀតត្រូវបានប្រតិបត្តិស្របគ្នា។

ការរឹតត្បិត

• កុំបើកដំណើរការប៉ារ៉ាឡែល ប្រសិនបើស្នូលទាំងអស់ជាប់រវល់ បើមិនដូច្នេះទេសំណើផ្សេងទៀតនឹងថយចុះ។
• សំខាន់បំផុត ដំណើរការប៉ារ៉ាឡែលជាមួយនឹងតម្លៃ WORK_MEM ខ្ពស់ប្រើអង្គចងចាំច្រើន - រាល់ hash join ឬ sort ប្រើអង្គចងចាំ work_mem ។
• សំណួរ OLTP ភាពយឺតយ៉ាវទាបមិនអាចបង្កើនល្បឿនដោយការប្រតិបត្តិស្របគ្នាបានទេ។ ហើយប្រសិនបើសំណួរត្រឡប់មួយជួរ ដំណើរការប៉ារ៉ាឡែលនឹងធ្វើឱ្យវាថយចុះប៉ុណ្ណោះ។
• អ្នកអភិវឌ្ឍន៍ចូលចិត្តប្រើស្តង់ដារ TPC-H ។ ប្រហែលជាអ្នកមានសំណួរស្រដៀងគ្នាសម្រាប់ការប្រតិបត្តិប៉ារ៉ាឡែលដ៏ល្អឥតខ្ចោះ។
• មានតែសំណួរ SELECT ដោយគ្មានការចាក់សោជាមុនប៉ុណ្ណោះដែលត្រូវបានប្រតិបត្តិស្របគ្នា។
• ពេលខ្លះការធ្វើលិបិក្រមត្រឹមត្រូវគឺប្រសើរជាងការស្កេនតារាងបន្តបន្ទាប់គ្នាក្នុងរបៀបប៉ារ៉ាឡែល។
• ការផ្អាកសំណួរ និងទស្សន៍ទ្រនិចមិនត្រូវបានគាំទ្រទេ។
• មុខងារ​បង្អួច និង​អនុគមន៍​សរុប​សំណុំ​ដែល​បាន​បញ្ជា​មិន​ស្រប​គ្នា​ទេ។
• អ្នកមិនទទួលបានអ្វីនៅក្នុងបន្ទុកការងារ I/O ទេ។
• មិនមានក្បួនដោះស្រាយការតម្រៀបស្របគ្នាទេ។ ប៉ុន្តែសំណួរដែលមានប្រភេទអាចត្រូវបានប្រតិបត្តិស្របគ្នាក្នុងទិដ្ឋភាពមួយចំនួន។
• ជំនួស CTE (ជាមួយ ... ) ជាមួយ SELECT ដែលត្រូវបានភ្ជាប់ដើម្បីបើកដំណើរការប៉ារ៉ាឡែល។
• ឧបករណ៍រុំទិន្នន័យភាគីទីបីមិនទាន់គាំទ្រដំណើរការប៉ារ៉ាឡែលនៅឡើយទេ (ប៉ុន្តែពួកគេអាច!)
• ការ​ចូលរួម​ពេញ​លេញ​មិន​ត្រូវ​បាន​គាំទ្រ​ទេ។
• max_rows បិទដំណើរការប៉ារ៉ាឡែល។
• ប្រសិនបើសំណួរមួយមានមុខងារដែលមិនត្រូវបានសម្គាល់ថា PARALLEL SAFE នោះវានឹងត្រូវបានដាក់ជាខ្សែតែមួយ។
• កម្រិតឯកោប្រតិបត្តិការ SERIALIZABLE បិទដំណើរការប៉ារ៉ាឡែល។

បរិស្ថានសាកល្បង

អ្នកអភិវឌ្ឍន៍ PostgreSQL បានព្យាយាមកាត់បន្ថយពេលវេលាឆ្លើយតបនៃសំណួរគោល TPC-H ។ ទាញយកគោលនិង សម្របវាទៅ PostgreSQL. នេះគឺជាការប្រើប្រាស់ក្រៅផ្លូវការនៃស្តង់ដារ TPC-H - មិនមែនសម្រាប់ការប្រៀបធៀបមូលដ្ឋានទិន្នន័យ ឬផ្នែករឹងទេ។

1. ទាញយក TPC-H_Tools_v2.17.3.zip (ឬកំណែថ្មីជាងនេះ) ពី TPC ក្រៅបណ្តាញ.
2. ប្តូរឈ្មោះ makefile.suite ទៅ Makefile ហើយប្តូរដូចដែលបានពិពណ៌នានៅទីនេះ៖ https://github.com/tvondra/pg_tpch . ចងក្រងកូដដោយប្រើពាក្យបញ្ជា make ។
3. បង្កើតទិន្នន័យ៖ ./dbgen -s 10 បង្កើតមូលដ្ឋានទិន្នន័យ 23 GB ។ នេះគឺគ្រប់គ្រាន់ដើម្បីមើលភាពខុសគ្នានៅក្នុងការអនុវត្តនៃសំណួរប៉ារ៉ាឡែលនិងមិនប៉ារ៉ាឡែល។
4. បម្លែងឯកសារ tbl в csv с for и sed.
5. ក្លូនឃ្លាំង pg_tpch និងចម្លងឯកសារ csv в pg_tpch/dss/data.
6. បង្កើតសំណួរដោយប្រើពាក្យបញ្ជា qgen.
7. ផ្ទុកទិន្នន័យទៅក្នុងមូលដ្ឋានទិន្នន័យដោយប្រើពាក្យបញ្ជា ./tpch.sh.

ការស្កេនតាមលំដាប់លំដោយ

វាអាចលឿនជាងមិនមែនដោយសារតែការអានស្របគ្នានោះទេ ប៉ុន្តែដោយសារតែទិន្នន័យត្រូវបានរីករាលដាលនៅទូទាំង CPU cores ជាច្រើន។ នៅក្នុងប្រព័ន្ធប្រតិបត្តិការទំនើប ឯកសារទិន្នន័យ PostgreSQL ត្រូវបានរក្សាទុកយ៉ាងល្អ។ ជាមួយនឹងការអានជាមុន វាអាចទៅរួចដើម្បីទទួលបានប្លុកធំជាងពីការផ្ទុកជាងសំណើ PG daemon ។ ដូច្នេះ ដំណើរការសំណួរមិនកំណត់ដោយឌីស I/O ទេ។ វាប្រើប្រាស់វដ្ត CPU ទៅ៖

• អានជួរដេកម្តងមួយៗពីទំព័រតារាង;
• ប្រៀបធៀបតម្លៃខ្សែអក្សរ និងលក្ខខណ្ឌ WHERE.

តោះដំណើរការសំណួរសាមញ្ញ select:

tpch=# explain analyze select l_quantity as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Seq Scan on lineitem (cost=0.00..1964772.00 rows=58856235 width=5) (actual time=0.014..16951.669 rows=58839715 loops=1)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 1146337
Planning Time: 0.203 ms
Execution Time: 19035.100 ms

ការស្កេនតាមលំដាប់លំដោយបង្កើតជួរច្រើនពេកដោយគ្មានការប្រមូលផ្តុំ ដូច្នេះសំណួរត្រូវបានប្រតិបត្តិដោយស្នូលស៊ីភីយូតែមួយ។

ប្រសិនបើអ្នកបន្ថែម SUM()អ្នកអាចមើលឃើញថាលំហូរការងារពីរនឹងជួយបង្កើនល្បឿនសំណួរ៖

explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 ms

ការប្រមូលផ្តុំប៉ារ៉ាឡែល

ថ្នាំង Parallel Seq Scan បង្កើតជួរដេកសម្រាប់ការប្រមូលផ្តុំដោយផ្នែក។ ថ្នាំង "ការប្រមូលផ្តុំដោយផ្នែក" កាត់បន្ទាត់ទាំងនេះដោយប្រើ SUM(). នៅចុងបញ្ចប់ បញ្ជរ SUM ពីដំណើរការកម្មករនិមួយៗត្រូវបានប្រមូលដោយថ្នាំង "Gather" ។

លទ្ធផលចុងក្រោយត្រូវបានគណនាដោយថ្នាំង "បញ្ចប់សរុប" ។ ប្រសិនបើអ្នកមានមុខងារប្រមូលផ្តុំផ្ទាល់ខ្លួនរបស់អ្នក កុំភ្លេចសម្គាល់ពួកវាជា "សុវត្ថិភាពស្របគ្នា"។

ចំនួនដំណើរការរបស់កម្មករ

ចំនួនដំណើរការរបស់កម្មករអាចកើនឡើងដោយមិនចាំបាច់ចាប់ផ្តើមម៉ាស៊ីនមេឡើងវិញ៖

explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 ms

តើមានអ្វីកើតឡើងនៅទីនេះ? មានដំណើរការការងារច្រើនជាង 2 ដង ហើយការស្នើសុំកាន់តែលឿនជាង 1,6599 ដង។ ការគណនាគួរឱ្យចាប់អារម្មណ៍។ យើងមានដំណើរការកម្មករ 2 នាក់ និងអ្នកដឹកនាំ 1 នាក់។ បន្ទាប់ពីការផ្លាស់ប្តូរវាបានក្លាយជា 4+1 ។

ល្បឿនអតិបរមារបស់យើងពីដំណើរការប៉ារ៉ាឡែល៖ 5/3 = 1,66(6) ដង។

តើវាដំណើរការយ៉ាងដូចម្តេច?

ដំណើរការ

សំណើប្រតិបត្តិតែងតែចាប់ផ្តើមជាមួយនឹងដំណើរការនាំមុខ។ អ្នកដឹកនាំធ្វើអ្វីគ្រប់យ៉ាងដែលមិនស្របគ្នា និងដំណើរការប៉ារ៉ាឡែលខ្លះ។ ដំណើរការផ្សេងទៀតដែលអនុវត្តសំណើដូចគ្នាត្រូវបានគេហៅថាដំណើរការកម្មករ។ ដំណើរការប៉ារ៉ាឡែលប្រើហេដ្ឋារចនាសម្ព័ន្ធ ដំណើរការបុគ្គលិកផ្ទៃខាងក្រោយថាមវន្ត (ពីកំណែ 9.4) ។ ដោយសារផ្នែកផ្សេងទៀតនៃ PostgreSQL ប្រើប្រាស់ដំណើរការជាជាងខ្សែស្រឡាយ សំណួរដែលមានដំណើរការកម្មករ 3 នាក់អាចលឿនជាងដំណើរការប្រពៃណី 4 ដង។

អន្តរកម្ម

ដំណើរការរបស់កម្មករទំនាក់ទំនងជាមួយអ្នកដឹកនាំតាមរយៈជួរសារ (ផ្អែកលើការចងចាំដែលបានចែករំលែក)។ ដំណើរការនីមួយៗមាន 2 ជួរ: សម្រាប់កំហុស និងសម្រាប់ tuples ។

តើត្រូវការលំហូរការងារប៉ុន្មាន?

ដែនកំណត់អប្បបរមាត្រូវបានបញ្ជាក់ដោយប៉ារ៉ាម៉ែត្រ max_parallel_workers_per_gather. បន្ទាប់មកអ្នករត់ការស្នើសុំយកដំណើរការរបស់កម្មករចេញពីអាងដែលកំណត់ដោយប៉ារ៉ាម៉ែត្រ max_parallel_workers size. ដែនកំណត់ចុងក្រោយគឺ max_worker_processesនោះគឺចំនួនសរុបនៃដំណើរការផ្ទៃខាងក្រោយ។

ប្រសិនបើមិនអាចបែងចែកដំណើរការកម្មករបានទេ ដំណើរការនឹងជាដំណើរការតែមួយ។

កម្មវិធីរៀបចំផែនការសំណួរអាចកាត់បន្ថយលំហូរការងារអាស្រ័យលើទំហំនៃតារាង ឬសន្ទស្សន៍។ មានប៉ារ៉ាម៉ែត្រសម្រាប់រឿងនេះ min_parallel_table_scan_size и min_parallel_index_scan_size.

set min_parallel_table_scan_size='8MB'
8MB table => 1 worker
24MB table => 2 workers
72MB table => 3 workers
x => log(x / min_parallel_table_scan_size) / log(3) + 1 worker

រាល់ពេលដែលតារាងធំជាង 3 ដង min_parallel_(index|table)_scan_size, Postgres បន្ថែមដំណើរការកម្មករ។ ចំនួនលំហូរការងារមិនផ្អែកលើការចំណាយទេ។ ភាពអាស្រ័យរាងជារង្វង់ធ្វើឱ្យការអនុវត្តស្មុគស្មាញពិបាក។ ផ្ទុយទៅវិញ អ្នករៀបចំផែនការប្រើច្បាប់សាមញ្ញ។

នៅក្នុងការអនុវត្ត ច្បាប់ទាំងនេះមិនតែងតែសមស្របសម្រាប់ការផលិតទេ ដូច្នេះអ្នកអាចផ្លាស់ប្តូរចំនួនដំណើរការកម្មករសម្រាប់តារាងជាក់លាក់មួយ៖ ALTER TABLE ... SET (parallel_workers = N).

ហេតុអ្វីបានជាដំណើរការប៉ារ៉ាឡែលមិនត្រូវបានប្រើ?

បន្ថែមពីលើបញ្ជីការរឹតបន្តឹងដ៏វែង វាក៏មានការត្រួតពិនិត្យតម្លៃផងដែរ៖

parallel_setup_cost - ដើម្បីជៀសវាងដំណើរការស្របគ្នានៃសំណើខ្លី។ ប៉ារ៉ាម៉ែត្រនេះប៉ាន់ស្មានពេលវេលាដើម្បីរៀបចំអង្គចងចាំ ចាប់ផ្តើមដំណើរការ និងការផ្លាស់ប្តូរទិន្នន័យដំបូង។

parallel_tuple_cost៖ ការប្រាស្រ័យទាក់ទងរវាងអ្នកដឹកនាំ និងកម្មករអាចត្រូវបានពន្យារពេលតាមសមាមាត្រទៅនឹងចំនួននៃ tuples ពីដំណើរការការងារ។ ប៉ារ៉ាម៉ែត្រនេះគណនាតម្លៃនៃការផ្លាស់ប្តូរទិន្នន័យ។

Nested Loop Joins

PostgreSQL 9.6+ может выполнять вложенные циклы параллельно — это простая операция.

explain (costs off) select c_custkey, count(o_orderkey)
                from    customer left outer join orders on
                                c_custkey = o_custkey and o_comment not like '%special%deposits%'
                group by c_custkey;
                                      QUERY PLAN
--------------------------------------------------------------------------------------
 Finalize GroupAggregate
   Group Key: customer.c_custkey
   ->  Gather Merge
         Workers Planned: 4
         ->  Partial GroupAggregate
               Group Key: customer.c_custkey
               ->  Nested Loop Left Join
                     ->  Parallel Index Only Scan using customer_pkey on customer
                     ->  Index Scan using idx_orders_custkey on orders
                           Index Cond: (customer.c_custkey = o_custkey)
                           Filter: ((o_comment)::text !~~ '%special%deposits%'::text)

ការប្រមូលផ្តុំកើតឡើងនៅដំណាក់កាលចុងក្រោយ ដូច្នេះ Nested Loop Left Join គឺជាប្រតិបត្តិការស្របគ្នា។ Parallel Index Only Scan ត្រូវបានណែនាំតែនៅក្នុងកំណែ 10។ វាដំណើរការស្រដៀងនឹងការស្កេនសៀរៀលប៉ារ៉ាឡែល។ លក្ខខណ្ឌ c_custkey = o_custkey អានការបញ្ជាទិញមួយក្នុងមួយជួរអតិថិជន។ ដូច្នេះវាមិនស្របគ្នាទេ។

Hash ចូលរួម

ដំណើរការរបស់កម្មករនិមួយៗបង្កើតតារាង hash ផ្ទាល់ខ្លួនរហូតដល់ PostgreSQL 11. ហើយប្រសិនបើមានដំណើរការលើសពីបួននេះ ដំណើរការនឹងមិនប្រសើរឡើងទេ។ នៅក្នុងកំណែថ្មី តារាង hash ត្រូវបានចែករំលែក។ ដំណើរការកម្មករនិមួយៗអាចប្រើ WORK_MEM ដើម្បីបង្កើតតារាងសញ្ញា។

select
        l_shipmode,
        sum(case
                when o_orderpriority = '1-URGENT'
                        or o_orderpriority = '2-HIGH'
                        then 1
                else 0
        end) as high_line_count,
        sum(case
                when o_orderpriority <> '1-URGENT'
                        and o_orderpriority <> '2-HIGH'
                        then 1
                else 0
        end) as low_line_count
from
        orders,
        lineitem
where
        o_orderkey = l_orderkey
        and l_shipmode in ('MAIL', 'AIR')
        and l_commitdate < l_receiptdate
        and l_shipdate < l_commitdate
        and l_receiptdate >= date '1996-01-01'
        and l_receiptdate < date '1996-01-01' + interval '1' year
group by
        l_shipmode
order by
        l_shipmode
LIMIT 1;
                                                                                                                                    QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=1964755.66..1964961.44 rows=1 width=27) (actual time=7579.592..7922.997 rows=1 loops=1)
   ->  Finalize GroupAggregate  (cost=1964755.66..1966196.11 rows=7 width=27) (actual time=7579.590..7579.591 rows=1 loops=1)
         Group Key: lineitem.l_shipmode
         ->  Gather Merge  (cost=1964755.66..1966195.83 rows=28 width=27) (actual time=7559.593..7922.319 rows=6 loops=1)
               Workers Planned: 4
               Workers Launched: 4
               ->  Partial GroupAggregate  (cost=1963755.61..1965192.44 rows=7 width=27) (actual time=7548.103..7564.592 rows=2 loops=5)
                     Group Key: lineitem.l_shipmode
                     ->  Sort  (cost=1963755.61..1963935.20 rows=71838 width=27) (actual time=7530.280..7539.688 rows=62519 loops=5)
                           Sort Key: lineitem.l_shipmode
                           Sort Method: external merge  Disk: 2304kB
                           Worker 0:  Sort Method: external merge  Disk: 2064kB
                           Worker 1:  Sort Method: external merge  Disk: 2384kB
                           Worker 2:  Sort Method: external merge  Disk: 2264kB
                           Worker 3:  Sort Method: external merge  Disk: 2336kB
                           ->  Parallel Hash Join  (cost=382571.01..1957960.99 rows=71838 width=27) (actual time=7036.917..7499.692 rows=62519 loops=5)
                                 Hash Cond: (lineitem.l_orderkey = orders.o_orderkey)
                                 ->  Parallel Seq Scan on lineitem  (cost=0.00..1552386.40 rows=71838 width=19) (actual time=0.583..4901.063 rows=62519 loops=5)
                                       Filter: ((l_shipmode = ANY ('{MAIL,AIR}'::bpchar[])) AND (l_commitdate < l_receiptdate) AND (l_shipdate < l_commitdate) AND (l_receiptdate >= '1996-01-01'::date) AND (l_receiptdate < '1997-01-01 00:00:00'::timestamp without time zone))
                                       Rows Removed by Filter: 11934691
                                 ->  Parallel Hash  (cost=313722.45..313722.45 rows=3750045 width=20) (actual time=2011.518..2011.518 rows=3000000 loops=5)
                                       Buckets: 65536  Batches: 256  Memory Usage: 3840kB
                                       ->  Parallel Seq Scan on orders  (cost=0.00..313722.45 rows=3750045 width=20) (actual time=0.029..995.948 rows=3000000 loops=5)
 Planning Time: 0.977 ms
 Execution Time: 7923.770 ms

សំណួរទី 12 ពី TPC-H បង្ហាញយ៉ាងច្បាស់នូវការភ្ជាប់សញ្ញាប៉ារ៉ាឡែល។ ដំណើរការកម្មករនិមួយៗរួមចំណែកដល់ការបង្កើតតារាងសញ្ញារួមមួយ។

បញ្ចូលចូលគ្នា

ការរួមបញ្ចូលគ្នានៃការរួមបញ្ចូលគ្នាគឺមិនស្របគ្នានៅក្នុងធម្មជាតិ។ កុំបារម្ភប្រសិនបើនេះជាជំហានចុងក្រោយនៃសំណួរ - វានៅតែអាចដំណើរការស្របគ្នា។

-- Query 2 from TPC-H
explain (costs off) select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment
from    part, supplier, partsupp, nation, region
where
        p_partkey = ps_partkey
        and s_suppkey = ps_suppkey
        and p_size = 36
        and p_type like '%BRASS'
        and s_nationkey = n_nationkey
        and n_regionkey = r_regionkey
        and r_name = 'AMERICA'
        and ps_supplycost = (
                select
                        min(ps_supplycost)
                from    partsupp, supplier, nation, region
                where
                        p_partkey = ps_partkey
                        and s_suppkey = ps_suppkey
                        and s_nationkey = n_nationkey
                        and n_regionkey = r_regionkey
                        and r_name = 'AMERICA'
        )
order by s_acctbal desc, n_name, s_name, p_partkey
LIMIT 100;
                                                QUERY PLAN
----------------------------------------------------------------------------------------------------------
 Limit
   ->  Sort
         Sort Key: supplier.s_acctbal DESC, nation.n_name, supplier.s_name, part.p_partkey
         ->  Merge Join
               Merge Cond: (part.p_partkey = partsupp.ps_partkey)
               Join Filter: (partsupp.ps_supplycost = (SubPlan 1))
               ->  Gather Merge
                     Workers Planned: 4
                     ->  Parallel Index Scan using <strong>part_pkey</strong> on part
                           Filter: (((p_type)::text ~~ '%BRASS'::text) AND (p_size = 36))
               ->  Materialize
                     ->  Sort
                           Sort Key: partsupp.ps_partkey
                           ->  Nested Loop
                                 ->  Nested Loop
                                       Join Filter: (nation.n_regionkey = region.r_regionkey)
                                       ->  Seq Scan on region
                                             Filter: (r_name = 'AMERICA'::bpchar)
                                       ->  Hash Join
                                             Hash Cond: (supplier.s_nationkey = nation.n_nationkey)
                                             ->  Seq Scan on supplier
                                             ->  Hash
                                                   ->  Seq Scan on nation
                                 ->  Index Scan using idx_partsupp_suppkey on partsupp
                                       Index Cond: (ps_suppkey = supplier.s_suppkey)
               SubPlan 1
                 ->  Aggregate
                       ->  Nested Loop
                             Join Filter: (nation_1.n_regionkey = region_1.r_regionkey)
                             ->  Seq Scan on region region_1
                                   Filter: (r_name = 'AMERICA'::bpchar)
                             ->  Nested Loop
                                   ->  Nested Loop
                                         ->  Index Scan using idx_partsupp_partkey on partsupp partsupp_1
                                               Index Cond: (part.p_partkey = ps_partkey)
                                         ->  Index Scan using supplier_pkey on supplier supplier_1
                                               Index Cond: (s_suppkey = partsupp_1.ps_suppkey)
                                   ->  Index Scan using nation_pkey on nation nation_1
                                         Index Cond: (n_nationkey = supplier_1.s_nationkey)

ថ្នាំង "បញ្ចូលគ្នា" មានទីតាំងនៅខាងលើ "ប្រមូលផ្តុំបញ្ចូលគ្នា" ។ ដូច្នេះការរួមបញ្ចូលគ្នាមិនប្រើដំណើរការប៉ារ៉ាឡែលទេ។ ប៉ុន្តែថ្នាំង "Parallel Index Scan" នៅតែជួយជាមួយផ្នែកនេះ។ part_pkey.

ការតភ្ជាប់តាមផ្នែក

នៅក្នុង PostgreSQL 11 ការតភ្ជាប់តាមផ្នែក បិទតាមលំនាំដើម៖ វាមានកាលវិភាគថ្លៃណាស់។ តារាងដែលមានភាគថាសស្រដៀងគ្នាអាចត្រូវបានភ្ជាប់គ្នាដោយភាគថាស។ វិធីនេះ Postgres នឹងប្រើតារាង hash តូចជាង។ ការភ្ជាប់គ្នានៃផ្នែកអាចស្របគ្នា។

tpch=# set enable_partitionwise_join=t;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
                    QUERY PLAN
---------------------------------------------------
 Append
   ->  Hash Join
         Hash Cond: (t2.b = t1.a)
         ->  Seq Scan on prt2_p1 t2
               Filter: ((b >= 0) AND (b <= 10000))
         ->  Hash
               ->  Seq Scan on prt1_p1 t1
                     Filter: (b = 0)
   ->  Hash Join
         Hash Cond: (t2_1.b = t1_1.a)
         ->  Seq Scan on prt2_p2 t2_1
               Filter: ((b >= 0) AND (b <= 10000))
         ->  Hash
               ->  Seq Scan on prt1_p2 t1_1
                     Filter: (b = 0)
tpch=# set parallel_setup_cost = 1;
tpch=# set parallel_tuple_cost = 0.01;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
                        QUERY PLAN
-----------------------------------------------------------
 Gather
   Workers Planned: 4
   ->  Parallel Append
         ->  Parallel Hash Join
               Hash Cond: (t2_1.b = t1_1.a)
               ->  Parallel Seq Scan on prt2_p2 t2_1
                     Filter: ((b >= 0) AND (b <= 10000))
               ->  Parallel Hash
                     ->  Parallel Seq Scan on prt1_p2 t1_1
                           Filter: (b = 0)
         ->  Parallel Hash Join
               Hash Cond: (t2.b = t1.a)
               ->  Parallel Seq Scan on prt2_p1 t2
                     Filter: ((b >= 0) AND (b <= 10000))
               ->  Parallel Hash
                     ->  Parallel Seq Scan on prt1_p1 t1
                           Filter: (b = 0)

រឿងចំបងគឺថាការតភ្ជាប់នៅក្នុងផ្នែកគឺស្របគ្នាលុះត្រាតែផ្នែកទាំងនេះមានទំហំធំល្មម។

ឧបសម្ព័ន្ធប៉ារ៉ាឡែល

ឧបសម្ព័ន្ធប៉ារ៉ាឡែល អាចត្រូវបានប្រើជំនួសឱ្យប្លុកផ្សេងគ្នានៅក្នុងលំហូរការងារផ្សេងគ្នា។ ជាធម្មតាវាកើតឡើងជាមួយនឹងសំណួរទាំងអស់របស់ UNION ។ គុណវិបត្តិ​គឺ​ភាព​ស្របគ្នា​តិច​ព្រោះ​ដំណើរការ​របស់​កម្មករ​និមួយៗ​ដំណើរការ​តែ​១​សំណើ​ប៉ុណ្ណោះ។

មានដំណើរការកម្មករចំនួន 2 កំពុងដំណើរការនៅទីនេះ ទោះបីជា 4 ត្រូវបានបើកក៏ដោយ។

tpch=# explain (costs off) select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day union all select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '2000-12-01' - interval '105' day;
                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Gather
   Workers Planned: 2
   ->  Parallel Append
         ->  Aggregate
               ->  Seq Scan on lineitem
                     Filter: (l_shipdate <= '2000-08-18 00:00:00'::timestamp without time zone)
         ->  Aggregate
               ->  Seq Scan on lineitem lineitem_1
                     Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)

អថេរសំខាន់បំផុត

• WORK_MEM កំណត់អង្គចងចាំក្នុងមួយដំណើរការ មិនមែនគ្រាន់តែជាសំណួរទេ៖ work_mem ដំណើរការ ការតភ្ជាប់ = ការចងចាំច្រើន។
• max_parallel_workers_per_gather - តើដំណើរការកម្មករប៉ុន្មាននាក់ដែលកម្មវិធីប្រតិបត្តិនឹងប្រើសម្រាប់ដំណើរការស្របគ្នាពីផែនការ។
• max_worker_processes - កែតម្រូវចំនួនសរុបនៃដំណើរការរបស់កម្មករទៅនឹងចំនួនស្នូលស៊ីភីយូនៅលើម៉ាស៊ីនមេ។
• max_parallel_workers - ដូចគ្នា ប៉ុន្តែសម្រាប់ដំណើរការការងារស្របគ្នា។

លទ្ធផល

ចាប់ពីកំណែ 9.6 ដំណើរការប៉ារ៉ាឡែលអាចធ្វើឱ្យប្រសើរឡើងយ៉ាងខ្លាំងនូវដំណើរការនៃសំណួរស្មុគស្មាញដែលស្កេនជួរឬលិបិក្រមជាច្រើន។ នៅក្នុង PostgreSQL 10 ដំណើរការប៉ារ៉ាឡែលត្រូវបានបើកតាមលំនាំដើម។ ចងចាំថាត្រូវបិទវានៅលើម៉ាស៊ីនមេដែលមានបន្ទុកការងារ OLTP ធំ។ ការស្កេនតាមលំដាប់លំដោយ ឬការស្កេនលិបិក្រមប្រើប្រាស់ធនធានច្រើន។ ប្រសិនបើអ្នកមិនដំណើរការរបាយការណ៍លើសំណុំទិន្នន័យទាំងមូលទេ អ្នកអាចកែលម្អដំណើរការសំណួរដោយគ្រាន់តែបន្ថែមលិបិក្រមដែលបាត់ ឬប្រើការបែងចែកត្រឹមត្រូវ។

សេចក្តីយោង

• https://www.postgresql.org/docs/11/how-parallel-query-works.html
• https://www.postgresql.org/docs/11/parallel-plans.html
• http://ashutoshpg.blogspot.com/2017/12/partition-wise-joins-divide-and-conquer.html
• http://rhaas.blogspot.com/2016/04/postgresql-96-with-parallel-query-vs.html
• http://amitkapila16.blogspot.com/2015/11/parallel-sequential-scans-in-play.html
• https://write-skew.blogspot.com/2018/01/parallel-hash-for-postgresql.html
• http://rhaas.blogspot.com/2017/03/parallel-query-v2.html
• https://blog.2ndquadrant.com/parallel-monster-benchmark/
• https://blog.2ndquadrant.com/parallel-aggregate/
• https://www.depesz.com/2018/02/12/waiting-for-postgresql-11-support-parallel-btree-index-builds/
• ភាពស្របគ្នានៅក្នុង PostgreSQL ១១

ប្រភព: www.habr.com