جدید CPUs میں بہت سارے کور ہوتے ہیں۔ برسوں سے، درخواستیں متوازی طور پر ڈیٹا بیس کو سوالات بھیج رہی ہیں۔ اگر یہ ایک ٹیبل میں ایک سے زیادہ قطاروں پر رپورٹ کا سوال ہے، تو یہ ایک سے زیادہ CPUs کا استعمال کرتے وقت تیزی سے چلتا ہے، اور PostgreSQL ورژن 9.6 کے بعد سے ایسا کرنے میں کامیاب رہا ہے۔
متوازی استفسار کی خصوصیت کو نافذ کرنے میں 3 سال لگے - ہمیں استفسار کے عمل کے مختلف مراحل پر کوڈ کو دوبارہ لکھنا پڑا۔ PostgreSQL 9.6 نے کوڈ کو مزید بہتر بنانے کے لیے انفراسٹرکچر متعارف کرایا۔ بعد کے ورژن میں، دیگر قسم کے سوالات متوازی طور پر انجام دیے جاتے ہیں۔
پابندیاں
- اگر تمام کور پہلے سے مصروف ہیں تو متوازی عمل کو فعال نہ کریں، ورنہ دیگر درخواستیں سست ہو جائیں گی۔
- سب سے اہم بات، اعلی WORK_MEM اقدار کے ساتھ متوازی پروسیسنگ بہت زیادہ میموری استعمال کرتی ہے - ہر ہیش جوائن یا ترتیب سے work_mem میموری لی جاتی ہے۔
- کم تاخیر والے OLTP سوالات کو متوازی عمل درآمد سے تیز نہیں کیا جا سکتا۔ اور اگر استفسار ایک قطار لوٹاتا ہے تو متوازی پروسیسنگ صرف اسے سست کر دے گی۔
- ڈویلپرز TPC-H بینچ مارک استعمال کرنا پسند کرتے ہیں۔ ہوسکتا ہے کہ آپ کے پاس کامل متوازی عمل کے لیے اسی طرح کے سوالات ہوں۔
- پریڈیکیٹ لاکنگ کے بغیر صرف SELECT سوالات کو متوازی طور پر انجام دیا جاتا ہے۔
- بعض اوقات مناسب اشاریہ سازی متوازی موڈ میں ترتیب وار ٹیبل اسکیننگ سے بہتر ہوتی ہے۔
- استفسارات اور کرسر کو روکنا تعاون یافتہ نہیں ہے۔
- ونڈو فنکشنز اور آرڈرڈ سیٹ ایگریگیٹ فنکشنز متوازی نہیں ہیں۔
- I/O کام کے بوجھ میں آپ کو کچھ حاصل نہیں ہوتا ہے۔
- کوئی متوازی ترتیب دینے والے الگورتھم نہیں ہیں۔ لیکن قسم کے سوالات کو کچھ پہلوؤں میں متوازی طور پر انجام دیا جاسکتا ہے۔
- متوازی پروسیسنگ کو فعال کرنے کے لیے CTE (WITH...) کو نیسٹڈ SELECT سے تبدیل کریں۔
- تھرڈ پارٹی ڈیٹا ریپرز ابھی تک متوازی پروسیسنگ کی حمایت نہیں کرتے ہیں (لیکن وہ کر سکتے ہیں!)
- مکمل بیرونی شمولیت تعاون یافتہ نہیں ہے۔
- max_rows متوازی پروسیسنگ کو غیر فعال کرتا ہے۔
- اگر کسی استفسار میں کوئی ایسا فنکشن ہے جس پر متوازی محفوظ کا نشان نہیں ہے، تو یہ سنگل تھریڈڈ ہوگا۔
- SERIALIZABLE ٹرانزیکشن آئسولیشن لیول متوازی پروسیسنگ کو غیر فعال کر دیتا ہے۔
ٹیسٹ ماحول
PostgreSQL ڈویلپرز نے TPC-H بینچ مارک سوالات کے جوابی وقت کو کم کرنے کی کوشش کی۔ بینچ مارک ڈاؤن لوڈ کریں اور . یہ TPC-H بینچ مارک کا غیر سرکاری استعمال ہے - ڈیٹا بیس یا ہارڈ ویئر کے مقابلے کے لیے نہیں۔
- ڈاؤن لوڈ TPC-H_Tools_v2.17.3.zip (یا نیا ورژن) .
- makefile.suite کا نام بدل کر Makefile اور تبدیل کریں جیسا کہ یہاں بیان کیا گیا ہے: . میک کمانڈ کے ساتھ کوڈ کو مرتب کریں۔
- ڈیٹا تیار کریں:
./dbgen -s 1023 جی بی ڈیٹا بیس بناتا ہے۔ متوازی اور غیر متوازی سوالات کی کارکردگی میں فرق دیکھنے کے لیے یہ کافی ہے۔ - فائلوں کو تبدیل کریں۔
tblвcsv с forиsed. - ذخیرہ کلون کریں۔
pg_tpchاور فائلوں کو کاپی کریں۔csvвpg_tpch/dss/data. - کمانڈ کے ساتھ سوالات بنائیں
qgen. - کمانڈ کے ساتھ ڈیٹا بیس میں ڈیٹا لوڈ کریں۔
./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 کاؤنٹر "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 قطاریں ہوتی ہیں: غلطیوں اور ٹیپلز کے لیے۔
کتنے ورک فلو کی ضرورت ہے؟
کم از کم حد پیرامیٹر کے ذریعہ بیان کی گئی ہے۔ . درخواست چلانے والا پھر پیرامیٹر کے ذریعہ محدود پول سے کارکن کے عمل کو لیتا ہے۔ . آخری حد ہے۔ ، یعنی پس منظر کے عمل کی کل تعداد۔
اگر کارکن کے عمل کو مختص کرنا ممکن نہیں تھا، تو پروسیسنگ واحد عمل ہوگی۔
استفسار پلانر ٹیبل یا انڈیکس کے سائز کے لحاظ سے ورک فلو کو کم کر سکتا ہے۔ اس کے لیے پیرامیٹرز ہیں۔ и .
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).
متوازی پروسیسنگ کیوں استعمال نہیں کی جاتی ہے؟
پابندیوں کی لمبی فہرست کے علاوہ، لاگت کے چیک بھی ہیں:
- مختصر درخواستوں کی متوازی کارروائی سے بچنے کے لیے۔ یہ پیرامیٹر میموری تیار کرنے، عمل شروع کرنے، اور ابتدائی ڈیٹا کے تبادلے کے وقت کا تخمینہ لگاتا ہے۔
: لیڈر اور کارکنوں کے درمیان رابطے میں تاخیر کام کے عمل سے ٹپلوں کی تعداد کے تناسب سے ہوسکتی ہے۔ یہ پیرامیٹر ڈیٹا ایکسچینج کی لاگت کا حساب لگاتا ہے۔
نیسٹڈ لوپ جوائن کرتا ہے۔
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)مجموعہ آخری مرحلے پر ہوتا ہے، اس لیے نیسٹڈ لوپ لیفٹ جوائن ایک متوازی آپریشن ہے۔ Parallel Index Only Scan صرف ورژن 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 msTPC-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)"Merge Join" نوڈ "Gather Merge" کے اوپر واقع ہے۔ لہذا انضمام متوازی پروسیسنگ کا استعمال نہیں کرتا ہے۔ لیکن "متوازی انڈیکس اسکین" نوڈ اب بھی طبقہ کے ساتھ مدد کرتا ہے۔ 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 عمل کنکشن = بہت زیادہ میموری۔
- - عمل درآمد کرنے والا پروگرام پلان سے متوازی پروسیسنگ کے لیے کتنے کارکن پروسیس کرے گا۔
- - سرور پر CPU کور کی تعداد میں کارکن کے عمل کی کل تعداد کو ایڈجسٹ کرتا ہے۔
- - ایک ہی، لیکن متوازی کام کے عمل کے لیے۔
کے نتائج
ورژن 9.6 کے مطابق، متوازی پروسیسنگ پیچیدہ سوالات کی کارکردگی کو بہت بہتر بنا سکتی ہے جو کئی قطاروں یا اشاریہ جات کو اسکین کرتی ہیں۔ PostgreSQL 10 میں، متوازی پروسیسنگ بطور ڈیفالٹ فعال ہے۔ ایک بڑے OLTP ورک بوجھ کے ساتھ سرورز پر اسے غیر فعال کرنا یاد رکھیں۔ ترتیب وار اسکین یا انڈیکس اسکین بہت سارے وسائل استعمال کرتے ہیں۔ اگر آپ پورے ڈیٹا سیٹ پر رپورٹ نہیں چلا رہے ہیں، تو آپ صرف گمشدہ اشاریہ جات کو شامل کر کے یا مناسب تقسیم کاری کا استعمال کر کے استفسار کی کارکردگی کو بہتر بنا سکتے ہیں۔
حوالہ جات
ماخذ: www.habr.com