Tha tòrr choraichean aig CPUan an latha an-diugh. Airson bliadhnaichean, tha tagraidhean air a bhith a’ cur cheistean gu stòran-dàta aig an aon àm. Mas e ceist aithisg a th’ ann air grunn shreathan ann an clàr, ruithidh e nas luaithe nuair a bhios tu a’ cleachdadh ioma CPU, agus tha PostgreSQL air a bhith comasach air seo a dhèanamh bho dhreach 9.6.
Thug e 3 bliadhna gus am feart ceiste co-shìnte a chuir an gnìomh - bha againn ri an còd ath-sgrìobhadh aig diofar ìrean de choileanadh na ceiste. Thug PostgreSQL 9.6 a-steach bun-structar gus tuilleadh leasachaidh a dhèanamh air a’ chòd. Ann an dreachan às deidh sin, thèid seòrsaichean cheistean eile a chuir gu bàs ann an co-shìnte.
Srian
- Na leig le coileanadh co-shìnte ma tha a h-uile cores trang mu thràth, air neo mairidh iarrtasan eile.
- Nas cudromaiche, bidh giullachd co-shìnte le luachan àrd WORK_MEM a ’cleachdadh tòrr cuimhne - bidh gach hash a’ tighinn còmhla no a sheòrsachadh a ’toirt suas cuimhne work_mem.
- Chan urrainnear ceistean OLTP latency ìosal a luathachadh le coileanadh co-shìnte. Agus ma thilleas a’ cheist aon sreath, cha dèan giollachd co-shìnte ach maill air.
- Is toil le luchd-leasachaidh an slat-tomhais TPC-H a chleachdadh. Is dòcha gu bheil ceistean co-chosmhail agad airson coileanadh co-shìnte foirfe.
- Chan eil ach ceistean SELECT às aonais glasadh ro-innse air an cur gu bàs aig an aon àm.
- Aig amannan tha clàr-amais ceart nas fheàrr na sganadh clàr sreath ann am modh co-shìnte.
- Chan eil taic ri stad air ceistean agus cursors.
- Chan eil gnìomhan uinneig agus gnìomhan iomlan òrdaichte co-shìnte.
- Chan fhaigh thu dad san eallach obrach I/O.
- Chan eil algorithms seòrsachaidh co-shìnte ann. Ach faodar ceistean le seòrsa a chur an gnìomh ann an co-shìnte ann an cuid de thaobhan.
- Cuir SELECT neadachaidh an àite CTE (WITH ...) gus a bhith comasach air giollachd co-shìnte.
- Chan eil pasgain dàta treas-phàrtaidh fhathast a’ toirt taic do ghiollachd co-shìnte (ach dh’ fhaodadh iad!)
- Chan eil taic ri FULL OUTER JOIN.
- tha max_rows a’ cur à comas giollachd co-shìnte.
- Ma tha gnìomh aig ceist nach eil air a chomharrachadh PARALLEL SAFE, bidh e le aon snàthainn.
- Tha an ìre iomallachd malairt SERIALIZABLE a’ dì-chomasachadh giollachd co-shìnte.
Àrainneachd deuchainn
Dh’ fheuch luchd-leasachaidh PostgreSQL ri ùine freagairt cheistean slat-tomhais TPC-H a lughdachadh. Luchdaich a-nuas an comharra-measaidh agus . Is e cleachdadh neo-oifigeil a tha seo de shlat-tomhais TPC-H - chan ann airson coimeas stòr-dàta no bathar-cruaidh.
- Luchdaich sìos TPC-H_Tools_v2.17.3.zip (no tionndadh nas ùire) .
- Ath-ainmich makefile.suite gu Makefile agus atharraich mar a tha air a mhìneachadh an seo: . Cruinnich an còd leis an òrdugh dèanamh.
- Cruthaich dàta:
./dbgen -s 10cruthaich stòr-dàta 23 GB. Tha seo gu leòr airson an eadar-dhealachadh fhaicinn ann an coileanadh cheistean co-shìnte agus neo-cho-shìnte. - Tionndaidh faidhlichean
tblвcsv с forиsed. - Clone an stòr
pg_tpchagus dèan lethbhreac de na faidhlicheancsvвpg_tpch/dss/data. - Cruthaich ceistean le òrdugh
qgen. - Luchdaich dàta a-steach don stòr-dàta leis an àithne
./tpch.sh.
Sganadh sreathach co-shìnte
Is dòcha gu bheil e nas luaithe chan ann air sgàth leughadh co-shìnte, ach air sgàth gu bheil an dàta air a sgaoileadh thairis air mòran de choraichean CPU. Ann an siostaman obrachaidh an latha an-diugh, tha faidhlichean dàta PostgreSQL air an tasgadh gu math. Le leughadh air thoiseach, tha e comasach bloc nas motha fhaighinn bho stòradh na tha an deamhan PG ag iarraidh. Mar sin, chan eil coileanadh ceist air a chuingealachadh le diosc I/O. Bidh e ag ithe cuairtean CPU gu:
- leugh sreathan aon aig aon àm bho dhuilleagan bùird;
- coimeas a dhèanamh eadar luachan sreang agus cumhaichean
WHERE.
Feuch an ruith sinn ceist shìmplidh 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 msBidh an sgrùdadh sreathach a’ toirt a-mach cus shreathan gun cho-chruinneachadh, agus mar sin thèid a’ cheist a chuir gu bàs le aon chridhe CPU.
Ma chuireas tu SUM(), chì thu gun cuidich dà shruth-obrach a’ cheist a luathachadh:
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 msCo-chruinneachadh co-shìnte
Bidh an nód Parallel Seq Scan a’ toirt a-mach sreathan airson cruinneachadh pàirt. Bidh an nód "Partial Aggregate" a 'trimadh nan loidhnichean sin a' cleachdadh SUM(). Aig an deireadh, tha an cuntair SUM bho gach pròiseas neach-obrach air a chruinneachadh leis an nód “Gather”.
Tha an toradh deireannach air a thomhas leis an nód “Finalize Aggregate”. Ma tha na gnìomhan cruinneachaidh agad fhèin, na dìochuimhnich an comharrachadh mar “sàbhailte co-shìnte”.
Àireamh de phròiseasan luchd-obrach
Faodar an àireamh de phròiseasan luchd-obrach àrdachadh gun a bhith ag ath-thòiseachadh an fhrithealaiche:
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 msDè tha dol an seo? Bha 2 uair a bharrachd de phròiseasan obrach ann, agus cha robh an t-iarrtas ach 1,6599 tursan nas luaithe. Tha an àireamhachadh inntinneach. Bha 2 phròiseas luchd-obrach againn agus 1 stiùiriche. Às deidh an atharrachaidh thàinig e gu bhith 4+1.
An astar as luaithe againn bho ghiollachd co-shìnte: 5/3 = 1,66 (6) amannan.
Ciamar a dh'obraicheas e?
Na pròiseasan
Bidh coileanadh iarrtas an-còmhnaidh a’ tòiseachadh leis a’ phrìomh phròiseas. Bidh an stiùiriche a’ dèanamh a h-uile càil neo-cho-shìnte agus beagan giollachd co-shìnte. Canar pròiseasan luchd-obrach ri pròiseasan eile a choileanas na h-aon iarrtasan. Bidh giollachd co-shìnte a’ cleachdadh bun-structair (bho dhreach 9.4). Leis gu bheil pàirtean eile de PostgreSQL a’ cleachdadh phròiseasan seach snàithleanan, dh’ fhaodadh ceist le pròiseasan luchd-obrach 3 a bhith 4 tursan nas luaithe na giullachd traidiseanta.
Eadar-obrachadh
Bidh pròiseasan luchd-obrach a’ conaltradh ris an stiùiriche tro ciudha teachdaireachd (stèidhichte air cuimhne co-roinnte). Tha 2 ciudha aig gach pròiseas: airson mearachdan agus airson tuples.
Cia mheud sruth-obrach a tha a dhìth?
Tha an ìre as ìsle air a shònrachadh leis a’ pharamadair . Bidh an ruitheadair iarrtas an uairsin a’ toirt pròiseasan luchd-obrach bhon amar cuibhrichte leis a’ pharamadair . Tha an cuingealachadh mu dheireadh , is e sin, an àireamh iomlan de phròiseasan cùl-fhiosrachaidh.
Mura robh e comasach pròiseas neach-obrach a riarachadh, bidh an giullachd mar aon phròiseas.
Faodaidh an dealbhaiche ceist sruthan-obrach a lughdachadh a rèir meud a’ bhùird no a’ chlàr-amais. Tha crìochan ann airson seo и .
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 workerGach uair a tha an clàr 3 tursan nas motha na min_parallel_(index|table)_scan_size, Postgres a 'cur pròiseas neach-obrach. Chan eil an àireamh de shruth-obrach stèidhichte air cosgaisean. Tha eisimeileachd cearcallach ga dhèanamh duilich buileachadh iom-fhillte. An àite sin, bidh an dealbhaiche a 'cleachdadh riaghailtean sìmplidh.
Ann an cleachdadh, chan eil na riaghailtean sin an-còmhnaidh freagarrach airson cinneasachadh, gus an urrainn dhut an àireamh de phròiseasan luchd-obrach atharrachadh airson clàr sònraichte: ALTER TABLE ... SET (parallel_workers = N).
Carson nach eilear a’ cleachdadh giollachd co-shìnte?
A bharrachd air an liosta fhada de chuingealachaidhean, tha sgrùdaidhean cosgais ann cuideachd:
- gus giullachd co-shìnte air iarrtasan goirid a sheachnadh. Tha am paramadair seo a 'toirt tuairmse air an ùine airson cuimhne ullachadh, tòiseachadh air a' phròiseas, agus iomlaid dàta tùsail.
: faodar dàil a chuir air conaltradh eadar an stiùiriche agus an luchd-obrach a rèir an àireamh de thuples bho phròiseasan obrach. Bidh am paramadair seo a’ tomhas cosgais iomlaid dàta.
Ceangal neadachaidh a’ tighinn còmhla
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)Tha an cruinneachadh a’ tachairt aig an ìre mu dheireadh, agus mar sin tha Nested Loop Left Join na ghnìomhachd co-shìnte. Chaidh Co-shìnte Index Only Scan a thoirt a-steach a-mhàin ann an dreach 10. Bidh e ag obair coltach ri sganadh sreathach co-shìnte. Staid c_custkey = o_custkey leugh aon òrdugh airson gach sreang teachdaiche. Mar sin chan eil e co-shìnte.
Thig còmhla Hash
Bidh gach pròiseas neach-obrach a 'cruthachadh a bhòrd hash fhèin gu PostgreSQL 11. Agus ma tha barrachd air ceithir de na pròiseasan sin ann, cha tig adhartas air coileanadh. Anns an dreach ùr, tha an clàr hash air a cho-roinn. Faodaidh gach pròiseas neach-obrach WORK_MEM a chleachdadh gus clàr hash a chruthachadh.
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 msTha ceist 12 bho TPC-H gu soilleir a’ sealltainn ceangal hash co-shìnte. Bidh gach pròiseas neach-obrach a’ cur ri cruthachadh clàr hash cumanta.
Thig còmhla
Tha ceangal co-aonaidh neo-cho-shìnte ann an nàdar. Na gabh dragh mas e seo an ceum mu dheireadh den cheist - faodaidh e ruith aig an aon àm fhathast.
-- 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)Tha an nód “Merge Join” suidhichte os cionn an “Gather Merge”. Mar sin chan eil aonadh a’ cleachdadh giollachd co-shìnte. Ach tha an nód “Co-shìnte Index Scan” fhathast a’ cuideachadh leis an earrainn part_pkey.
Ceangal le earrannan
Ann am PostgreSQL 11 ciorramach gu bunaiteach: tha clàr-ama gu math daor aige. Faodar bùird le sgaradh co-chosmhail a cheangal ri sgaradh le sgaradh. San dòigh seo cleachdaidh Postgres clàran hash nas lugha. Faodaidh gach ceangal de earrannan a bhith co-shìnte.
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)Is e am prìomh rud gu bheil an ceangal ann an earrannan co-shìnte a-mhàin ma tha na h-earrannan sin mòr gu leòr.
Pàipear-taice co-shìnte
faodar a chleachdadh an àite diofar bhlocaichean ann an sruthan obrach eadar-dhealaichte. Mar as trice bidh seo a’ tachairt le ceistean UNION ALL. Tha an ana-cothrom nas lugha de cho-shìnteachd, oir chan eil gach pròiseas neach-obrach a 'pròiseas ach 1 iarrtas.
Tha 2 phròiseas luchd-obrach a’ ruith an seo, ged a tha 4 air an comasachadh.
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)Na caochladairean as cudromaiche
- Bidh WORK_MEM a’ cuingealachadh cuimhne gach pròiseas, chan e dìreach ceistean: work_mem pròiseasan ceanglaichean = tòrr cuimhne.
- - cia mheud pròiseas neach-obrach a chleachdas am prògram gnìomh airson giullachd co-shìnte bhon phlana.
- - ag atharrachadh an àireamh iomlan de phròiseasan luchd-obrach a rèir an àireamh de choraichean CPU air an fhrithealaiche.
- - an aon rud, ach airson pròiseasan obrach co-shìnte.
Builean
Mar an dreach 9.6, faodaidh giollachd co-shìnte leasachadh mòr a thoirt air coileanadh cheistean iom-fhillte a bhios a’ sganadh mòran shreathan no chlàran-amais. Ann am PostgreSQL 10, tha giullachd co-shìnte air a chomasachadh gu bunaiteach. Cuimhnich gun cuir thu dheth e air frithealaichean le eallach obrach mòr OLTP. Bidh sganaidhean sreath no sganaidhean clàr-amais ag ithe mòran ghoireasan. Mura h-eil thu a’ ruith aithisg air an t-seata dàta gu lèir, faodaidh tu coileanadh ceist a leasachadh le bhith dìreach a’ cur clàran-amais a tha a dhìth no a’ cleachdadh sgaradh ceart.
iomraidhean
Source: www.habr.com