ProHoster > بلاګ > اداره > په PostgreSQL کې موازي پوښتنې

په PostgreSQL کې موازي پوښتنې

په PostgreSQL کې موازي پوښتنې
عصري CPUs ډیری کورونه لري. د کلونو لپاره، غوښتنلیکونه په موازي ډول ډیټابیسونو ته پوښتنې لیږي. که دا په جدول کې په څو قطارونو کې د راپور پوښتنه وي، دا د ډیری CPUs کارولو په وخت کې ګړندی پرمخ ځي، او PostgreSQL د 9.6 نسخه راهیسې دا کار کولو توان لري.

د موازي پوښتنې ځانګړتیا پلي کولو لپاره 3 کاله وخت ونیو - موږ باید د پوښتنو اجرا کولو په مختلف مرحلو کې کوډ بیا ولیکل. PostgreSQL 9.6 د کوډ نور ښه کولو لپاره زیربنا معرفي کړه. په راتلونکو نسخو کې، د پوښتنو نور ډولونه په موازي توګه اجرا کیږي.

محدودیتونه

  • موازي اجرا کول مه کوئ که ټول کورونه لا دمخه بوخت وي، که نه نو نورې غوښتنې به ورو شي.
  • تر ټولو مهم، د لوړ WORK_MEM ارزښتونو سره موازي پروسس کول ډیری حافظه کاروي - هر هش یوځای یا ترتیب د work_mem حافظه اخلي.
  • د ټیټ ځنډ OLTP پوښتنې موازي اجرا کولو سره ګړندۍ نشي. او که چیرې پوښتنه یو قطار بیرته راولي، موازي پروسس به یوازې دا ورو کړي.
  • پراختیا کونکي د TPC-H بنچمارک کارولو سره مینه لري. شاید تاسو د کامل موازي اجرا کولو لپاره ورته پوښتنې لرئ.
  • یوازې د انتخاب پوښتنې پرته له وړاندوینې لاک کولو څخه په موازي ډول اجرا کیږي.
  • ځینې ​​​​وختونه مناسب لیست کول په موازي حالت کې د ترتیب شوي میز سکین کولو څخه غوره دي.
  • د پوښتنو ځنډول او کرسر نه ملاتړ کیږي.
  • د کړکۍ افعال او ترتیب شوي ټولیز افعال موازي ندي.
  • تاسو د I/O کاري بار کې هیڅ شی نه ترلاسه کوئ.
  • هیڅ موازي ترتیب کولو الګوریتمونه شتون نلري. مګر د ډولونو سره پوښتنې په ځینو اړخونو کې په موازي ډول اجرا کیدی شي.
  • د موازي پروسس کولو وړ کولو لپاره CTE (سره ...) د نیسټ شوي انتخاب سره بدل کړئ.
  • د دریمې ډلې ډیټا ریپرز لاهم د موازي پروسس کولو ملاتړ نه کوي (مګر دوی کولی شي!)
  • بشپړ بهر یوځای کیدل نه ملاتړ کیږي.
  • 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 . کوډ د میک کمانډ سره تالیف کړئ.
  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 کورونو کې خپریږي. په عصري عملیاتي سیسټمونو کې، د PostgreSQL ډیټا فایلونه په ښه توګه ساتل کیږي. د مخکې لوستلو سره ، دا ممکنه ده چې د PG ډیمون غوښتنو په پرتله د ذخیره کولو څخه لوی بلاک ترلاسه کړئ. نو ځکه، د پوښتنو فعالیت د ډیسک 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

د ترتیب سکین د راټولولو پرته ډیری قطارونه تولیدوي، نو دا پوښتنه د یو واحد CPU کور لخوا اجرا کیږي.

که تاسو اضافه کړئ 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

موازي راټولول

د موازي سیق سکین نوډ د جزوی راټولولو لپاره قطارونه تولیدوي. "جزوي مجموعه" نوډ دا کرښې په کارولو سره کموي SUM(). په پای کې، د هر کارګر پروسې څخه 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

دلته څه روان دي؟ 2 ځله ډیر کاري پروسې شتون درلود، او غوښتنه یوازې 1,6599 ځله چټکه شوه. محاسبې په زړه پورې دي. موږ د 2 کارګر بهیر او 1 مشر درلود. د بدلون وروسته دا 4+1 شو.

د موازي پروسس کولو څخه زموږ اعظمي سرعت: 5/3 = 1,66 (6) ځله.

دا څنګه کار کوي؟

پروسې

د غوښتنې اجرا کول تل د مخکښ پروسې سره پیل کیږي. مشر هر څه غیر موازي او ځینې موازي پروسس کوي. نورې پروسې چې ورته غوښتنې ترسره کوي د کارګر پروسې په نوم یادیږي. موازي پروسس زیربنا کاروي د متحرک شالید کارګر پروسې (د 9.4 نسخه څخه). څرنګه چې د PostgreSQL نورې برخې د تارونو پرځای پروسې کاروي، د 3 کارګر پروسو سره یوه پوښتنه د دودیز پروسس کولو په پرتله 4 ځله ګړندۍ کیدی شي.

متقابل عمل

د کارکونکي پروسې د پیغام کتار له لارې مشر سره اړیکه نیسي (د ګډې حافظې پراساس). هره پروسه دوه کتارونه لري: د غلطیو لپاره او د ټپلونو لپاره.

څومره کاري فلو ته اړتیا ده؟

لږترلږه حد د پیرامیټر لخوا مشخص شوی 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: د مشر او کارکونکو تر منځ اړیکي د کاري پروسو څخه د ټپلونو د شمیر په تناسب ځنډول کیدی شي. دا پیرامیټر د معلوماتو تبادلې لګښت محاسبه کوي.

Nested Loop یوځای کیږي

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)

راټولول په وروستي پړاو کې واقع کیږي، نو د نیسټډ لوپ لیف جوین یو موازي عملیات دی. یوازې موازي شاخص سکین یوازې په 10 نسخه کې معرفي شوی. دا د موازي سیریل سکینګ سره ورته کار کوي. حالت c_custkey = o_custkey د هر پیرودونکي تار یو امر لوستل کیږي. نو دا موازي نه ده.

هش یوځای کیدل

هر کارګر پروسه تر PostgreSQL 11 پورې خپل هش میز جوړوي. او که چیرې د دې پروسو څخه څلور څخه زیات وي، فعالیت به ښه نشي. په نوې نسخه کې، د هش میز شریک شوی. هر کارګر پروسه کولی شي د هش میز جوړولو لپاره 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

د TPC-H څخه 12 پوښتنه په واضح ډول د موازي هش اړیکه ښیې. د هر کارګر پروسه د ګډ هش میز په جوړولو کې مرسته کوي.

یوځای کول

یوځای کیدل په طبیعت کې غیر موازي دي. اندیښنه مه کوئ که دا د پوښتنې وروستی مرحله وي - دا لاهم په موازي توګه پرمخ وړل کیدی شي.

-- 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)

د "ضم کولو یوځای کول" نوډ د "ګدر انضمام" پورته موقعیت لري. نو یوځای کول موازي پروسس نه کاروي. مګر د "موازي شاخص سکین" نوډ لاهم د برخې سره مرسته کوي part_pkey.

د برخو په واسطه نښلول

په PostgreSQL 11 کې د برخو سره اړیکه د ډیفالټ لخوا غیر فعال شوی: دا خورا ګران مهال ویش لري. میزونه د ورته ویش سره یوځای کیدی شي د ویشلو په واسطه ویشل کیږي. پدې توګه پوسټګریس به کوچني هش میزونه وکاروي. د برخو هر ارتباط موازي کیدی شي.

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)

اصلي شی دا ده چې په برخو کې اړیکه موازي ده که چیرې دا برخې په کافي اندازه لوی وي.

موازي ضمیمه

موازي ضمیمه په مختلف کاري جریانونو کې د مختلف بلاکونو پرځای کارول کیدی شي. دا معمولا د اتحادیې ټولو پوښتنو سره پیښیږي. نیمګړتیا لږ موازي ده، ځکه چې د هر کارګر پروسه یوازې د 1 غوښتنې پروسس کوي.

دلته د کارګرانو 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 - په سرور کې د CPU کور شمیر ته د کارګر پروسو ټولیز شمیر تنظیموي.
  • max_parallel_workers - ورته، مګر د موازي کاري پروسو لپاره.

پایلې

د 9.6 نسخه پورې، موازي پروسس کولی شي د پیچلو پوښتنو فعالیت خورا ښه کړي چې ډیری قطارونه یا شاخصونه سکین کوي. په PostgreSQL 10 کې، موازي پروسس کول د ډیفالټ په واسطه فعال شوي. په یاد ولرئ چې دا په سرورونو کې د لوی OLTP کاري بار سره غیر فعال کړئ. ترتیب سکین یا د شاخص سکین ډیری سرچینې مصرفوي. که تاسو په ټول ډیټا سیټ کې راپور نه چلوئ، تاسو کولی شئ په ساده ډول د ورک شوي شاخصونو په اضافه کولو یا د مناسب تقسیم کولو په کارولو سره د پوښتنو فعالیت ښه کړئ.

مرجع

سرچینه: www.habr.com

Add a comment