🥇Paralleelsed päringud PostgreSQL-s

Kaasaegsetes protsessorites on väga palju südamikke. Aastaid on rakendused andmebaasidele päringute saatmiseks töötanud paralleelselt. Kui see on aruande päring, mis hõlmab mitmeid tabeleid, siis toimub see kiiremini, kui kasutatakse mitut protsessorit, ja PostgreSQL-is on see võimalik alates versioonist 9.6.

Kulutasime 3 aastat paralleelsete päringute funktsiooni rakendamisele — tuli kirjutada kood ümber erinevatel päringu täitmise etappidel. PostgreSQL 9.6 tõi kaasa infrastruktuuri koodi edasiseks täiustamiseks. Hilisemates versioonides saavad ka teised päringutüübid töötada paralleelselt.

Piirangud

Ärge lülitage paralleelset täitmist sisse, kui kõik protsessorisüdamikud on juba hõivatud, vastasel juhul aeglustavad teised päringud.
Peamine asi on see, et kõrge WORK_MEM väärtusega paralleelne töötlemine kasutab palju mälu — iga hash-ühendus või sortimine vajab mälu vastavalt work_mem-i mahule.
OLTP päringud, millel on madal latentsus, ei saa paralleelse täitmisega kiiremaks muutuda. Ja kui päring tagastab ainult ühe rea, siis päringute paralleelne töötlemine ainult aeglustab seda.
Arendajad armastavad kasutada TPC-H tulemusi. Võib-olla on teil sarnaseid päringuid ideaalse paralleelse täitmise jaoks.
Ainult SELECT päringud, millel ei ole predikaadi lukustust, saavad töötada paralleelselt.
Mõnikord on õige indekseerimine parem kui tabeli järjestikune skaneerimine paralleelses režiimis.
Päringute peatamine ja kursused ei ole toetatud.
Aknafunktsioonid ja järjestatud komplektide agregaadifunktsioonid ei ole paralleelsed.
Te ei saavutada sisend-väljund koormuses midagi.
Paralleelseid järjestusalgoritme ei eksisteeri. Kuid sortimiseta päringud saavad mõnedes aspektides töötada paralleelselt.
Asendage CTE (WITH …) sisemise SELECT-iga, et lubada paralleelset töötlemist.
Kolmandate osapoolte andmete mähised ei toeta veel paralleelset töötlemist (kuigi võiks!).
FULL OUTER JOIN ei ole toetatud.
max_rows välistab paralleelse töötlemise.
Kui päringus on funktsioon, mida ei ole märgitud kui PARALLEL SAFE, on see ühe protsessoriga.
Tehingute isolatsiooni tase SERIALIZABLE välistab paralleelse töötlemise.

Testimisalune

PostgreSQL arendajad püüdsid vähendada TPC-H mõõtmise päringute reageerimise aega. Laadige alla mõõtmine ja kohandage see PostgreSQL-iga. See TPC-H mõõtmise mitteametlik kasutamine ei ole mõeldud andmebaaside või varustuse võrdlemiseks.

Lae alla TPC-H_Tools_v2.17.3.zip (või uuem versioon) TPC veebisaidilt.
Nimeta makefile.suite ümber Makefile'iks ja muuda nagu siin on kirjeldatud: https://github.com/tvondra/pg_tpch . Koodi kompileerimiseks kasuta käsku make.
Genereeri andmed: .\/dbgen -s 10 loomiseks suurus 23 GB. Seda on piisavalt, et näha erinevusi paralleelsete ja mitteparalleelsete päringute tulemustes.
Muuda failid tbl ja csv for ja sed.
Kloonige hoidla pg_tpch ja kopeerige failid csv ja pg_tpch\/dss\/data.
Looge päringud käsuga qgen.
Laadige andmed andmebaasi käsuga .\/tpch.sh.

Paralleelne järjestikune skaneerimine

See võib olla kiirem mitte paralleelse lugemise tõttu, vaid kuna andmed on jaotatud paljude protsessorituumade vahel. Kaasaegsetes opsüsteemides PostgreSQL andmefailid vahemälustuvad hästi. Eelneva lugemise abil saab salvestusmuutjalt lugeda rohkem plokke, kui PG teenus nõuab. Seetõttu ei piira päringu jõudlus ketta sisend-väljundit. See kulutab protsessori tsükleid, et:

lugeda ridu ükshaaval tabeli lehtedelt;
võrrelda ridade väärtusi ja tingimusi KUS.

Teeme lihtsa päringu select:

tpch=# selgita analüüsi päringut select l_quantity as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
KÜSIMUSE PLaan
--------------------------------------------------------------------------------------------------------------------------
Järjekordne skaneerimine lineitem (kulu=0.00..1964772.00 read=58856235 laius=5) (aktiivne aeg=0.014..16951.669 read=58839715 tsüklid=1)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp ilma ajavööndita)
Filtri järgi eemaldatud read: 1146337
Planeerimise aeg: 0.203 ms
Teostamise aeg: 19035.100 ms

Järjekordne skaneerimine annab liigselt ridu ilma agregatsioonita, nii et päring tehakse ühe protsessorituuma poolt.

Kui lisada SUM(), on näha, et kaks tööhõivet aitavad päringu kiirusel:

selgita analüüsi päringut select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
KÜSIMUSE PLaan
----------------------------------------------------------------------------------------------------------------------------------------------------
Lõpeta agregaat (kulu=1589702.14..1589702.15 read=1 laius=32) (aktiivne aeg=8553.365..8553.365 read=1 tsüklid=1)
-> Koguge (kulu=1589701.91..1589702.12 read=2 laius=32) (aktiivne aeg=8553.241..8555.067 read=3 tsüklid=1)
Plaanitavad töötajad: 2
Käivitatud töötajad: 2
-> Osaline agregaat (kulu=1588701.91..1588701.92 read=1 laius=32) (aktiivne aeg=8547.546..8547.546 read=1 tsüklid=3)
-> Paralleelne järjekordne skaneerimine lineitem (kulu=0.00..1527393.33 read=24523431 laius=5) (aktiivne aeg=0.038..5998.417 read=19613238 tsüklid=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp ilma ajavööndita)
Filtri järgi eemaldatud read: 382112
Planeerimise aeg: 0.241 ms
Teostamise aeg: 8555.131 ms

Paralleelne agregatsioon

Sõlm „Paralleelne järjekordne skaneerimine“ genereerib ridu osalisteks agregatsioonideks. Sõlm „Osaline agregaat“ kärbib neid ridu SUM(). Lõpus kogub iga töötaja SUM-i loenduri sõlm „Kogu“.

Lõplik tulemus arvutatakse sõlmes „Finalize Aggregate“. Kui teil on oma aggregeerimisfunktsioonid, ärge unustage neid märkida kui „parallel safe.“

Tööprotsesside arv

Tööprotsesside arvu saab suurendada ilma serveri taaskäivitamiseta:

selgita analüüsi päringut select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
KÜSIMUSE PLaan
----------------------------------------------------------------------------------------------------------------------------------------------------
Lõpeta agregaat (kulu=1589702.14..1589702.15 read=1 laius=32) (aktiivne aeg=8553.365..8553.365 read=1 tsüklid=1)
-> Koguge (kulu=1589701.91..1589702.12 read=2 laius=32) (aktiivne aeg=8553.241..8555.067 read=3 tsüklid=1)
Plaanitavad töötajad: 2
Käivitatud töötajad: 2
-> Osaline agregaat (kulu=1588701.91..1588701.92 read=1 laius=32) (aktiivne aeg=8547.546..8547.546 read=1 tsüklid=3)
-> Paralleelne järjekordne skaneerimine lineitem (kulu=0.00..1527393.33 read=24523431 laius=5) (aktiivne aeg=0.038..5998.417 read=19613238 tsüklid=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp ilma ajavööndita)
Filtri järgi eemaldatud read: 382112
Planeerimise aeg: 0.241 ms
Teostamise aeg: 8555.131 ms

Mis siin juhtub? Tööprotsesside arv on kahekordistunud, kuid päring on muutunud vaid 1,6599 korda kiiremaks. Arvutused on huvitavad. Meil oli 2 tööprotsessi ja 1 juht. Pärast muutmist on see 4+1.

Meie maksimaalne kiirus, mis tuleneb paralleelsest töötlemisest: 5/3 = 1,66(6) korda.

Kuidas see töötab?

Protsessid

Päringu täitmine algab alati juhtimisprotsessist. Juht tegeleb kõigi mitte-paralleelsete ja osa paralleelse töötlemisega. Teisi protsesse, mis täidavad samu päringuid, nimetatakse tööprotsessideks. Paralleelne töötlemine kasutab infrastruktuuri dünaamiliste taustatööprotsesside (alates versioonist 9.4). Kuna PostgreSQL muud osad kasutavad protsesse, mitte lõime, võis päring 3 tööprotsessiga olla 4 korda kiirem traditsioonilisest töötlemisest.

Koostöö

Tööprotsessid suhtlevad juhiga sõnumijärjekorra kaudu (üldise mälu põhjal). Igal protsessil on 2 järjekorda: veaparanduse ja tuplede jaoks.

Kui palju tööprotsesse on vaja?

Minimaalne piirang määrab parameeter max_parallel_workers_per_gather. Siis päringute täitja võtab tööprotsessid basseinist, mida piirab parameeter max_parallel_workers size. Viimane piirang on max_worker_processes, st taustprotsesside koguarv.

Kui tööprotsessi eraldamine ebaõnnestub, on töötlemine ühes protsessis.

Päringute planeerija võib vähendada tööprotsesside arvu tabeli või indeksi suuruse põhjal. Selleks on olemas parameetrid min_parallel_table_scan_size ja min_parallel_index_scan_size.

set min_parallel_table_scan_size='8MB'
8MB tabel => 1 töötaja
24MB tabel => 2 töötajat
72MB tabel => 3 töötajat
x => log(x / min_parallel_table_scan_size) / log(3) + 1 töötaja

Igal korral, kui tabel on 3 korda suurem kui min_parallel_(index|table)_scan_size, lisab Postgres tööprotsessi. Tööprotsesside arv ei põhine kuludel. Ringikujuline sõltuvus raskendab keeruliste rakenduste loomist. Selle asemel kasutab planeerija lihtsaid reegleid.

Praktikas ei ole need reeglid alati tootmisoludes sobivad, seega on võimalik muuta tööprotsesside arvu konkreetse tabeli jaoks: ALTER TABLE … SET (parallel_workers = N).

Miks paralleelset töötlemist ei kasutata?

Lisaks pika nimekirja piirangutele on veel kulude kontrollid:

parallel_setup_cost — et vältida lühikeste päringute paralleelset töötlemist. See parameeter hindab mälu ettevalmistamise, protsessi käivitamise ja esialgse andmevahetuse aega.

parallel_tuple_cost: juhendaja vahetus teiste töötajatega võib pikendada proportsionaalselt töötlemiste arvu tõttu. See parameeter arvestab andmevahetuse kulusid.

Sisemised tsüklite ühendused — Nested Loop Join

PostgreSQL 9.6+ suudab paralleelselt täita pesatud tsüklit — see on lihtne operatsioon.

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 '%specialposits%'
 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 !~~ '%specialposits%'::text)

Kogumine toimub viimases etapis, seega on Nested Loop Left Join paralleelne operatsioon. Parallel Index Only Scan ilmus alles versioonis 10. See töötab sarnaselt paralleelsele järjestikusele skaneerimisele. Tingimus c_custkey = o_custkey loeb iga kliendi rea jaoks ühe tellimuse. Seega see ei ole paralleelne.

Rohesidel ühendamine — Hash Join

Iga töötlemisprotsess loob oma häshtiabeli kuni PostgreSQL 11. Ja kui neid protsesse on rohkem kui neli, ei parane jõudlus. Uues versioonis on hästitaabel ühine. Iga töötlemisprotsess võib kasutada WORK_MEM, et luua häshtiabel.

valige
        l_shipmode,
        sum(case
                kui o_orderpriority = '1-URGENT'
                        või o_orderpriority = '2-HIGH'
                        siis 1
                muu juhul 0
        end) kui high_line_count,
        sum(case
                kui o_orderpriority  '1-URGENT'
                        ja o_orderpriority  '2-HIGH'
                        siis 1
                muu juhul 0
        end) kui low_line_count
alates
        orders,
        lineitem
kui
        o_orderkey = l_orderkey
        ja l_shipmode in ('MAIL', 'AIR')
        ja l_commitdate < l_receiptdate
        ja l_shipdate = kuupäev '1996-01-01'
        ja l_receiptdate < kuupäev '1996-01-01' + intervall '1' aasta
rühmitama
        l_shipmode
järjestama
        l_shipmode
PIIRDED 1;
                                                                                                                                    KÜSIMUSE PLANEERIMINE
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Piirang (kulud=1964755.66..1964961.44 read=1 laius=27) (tegelik aeg=7579.592..7922.997 read=1 tsüklis=1)
   ->  Finalize GroupAggregate  (kulud=1964755.66..1966196.11 read=7 laius=27) (tegelik aeg=7579.590..7579.591 read=1 tsüklis=1)
         Rühma võti: lineitem.l_shipmode
         ->  Gather Merge  (kulud=1964755.66..1966195.83 read=28 laius=27) (tegelik aeg=7559.593..7922.319 read=6 tsüklis=1)
               Planeeritud töötajad: 4
               Alustatud töötajad: 4
               ->  Partial GroupAggregate  (kulud=1963755.61..1965192.44 read=7 laius=27) (tegelik aeg=7548.103..7564.592 read=2 tsüklis=5)
                     Rühma võti: lineitem.l_shipmode
                     ->  Sort  (kulud=1963755.61..1963935.20 read=71838 laius=27) (tegelik aeg=7530.280..7539.688 read=62519 tsüklis=5)
                           Sortimisvõti: lineitem.l_shipmode
                           Sortimise meetod: välispidine liitmine Disk: 2304kB
                           Tööline 0:  Sortimise meetod: välispidine liitmine Disk: 2064kB
                           Tööline 1:  Sortimise meetod: välispidine liitmine Disk: 2384kB
                           Tööline 2:  Sortimise meetod: välispidine liitmine Disk: 2264kB
                           Tööline 3:  Sortimise meetod: välispidine liitmine Disk: 2336kB
                           ->  Parallel Hash Join  (kulud=382571.01..1957960.99 read=71838 laius=27) (tegelik aeg=7036.917..7499.692 read=62519 tsüklis=5)
                                 Hash Tingimus: (lineitem.l_orderkey = orders.o_orderkey)
                                 ->  Parallel Seq Scan on lineitem  (kulud=0.00..1552386.40 read=71838 laius=19) (tegelik aeg=0.583..4901.063 read=62519 tsüklis=5)
                                       Filter: ((l_shipmode = ANY ('{MAIL,AIR}'::bpchar[])) JA (l_commitdate < l_receiptdate) JA (l_shipdate = '1996-01-01'::kuupäev) JA (l_receiptdate < '1997-01-01 00:00:00'::aeg ilma ajavööndita))
                                       Ridu eemaldatud filtrist: 11934691
                                 ->  Parallel Hash  (kulud=313722.45..313722.45 read=3750045 laius=20) (tegelik aeg=2011.518..2011.518 read=3000000 tsüklis=5)
                                       Baki: 65536  Partiid: 256  Mälu kasutus: 3840kB
                                       ->  Parallel Seq Scan on orders  (kulud=0.00..313722.45 read=3750045 laius=20) (tegelik aeg=0.029..995.948 read=3000000 tsüklis=5)
 Planeerimise aeg: 0.977 ms
 Täitmise aeg: 7923.770 ms

Küsimus 12 TPC-H näitab selgelt parallelset räsivõrku. Iga tööprotsess osaleb ühise räsitabeli loomisel.

Ühendamine koondamisega — Merge Join

Ühendamine koondamisega on olemuselt mitteparalleelne. Ära muretse, kui see on päringu viimane etapp, — see võib ikkagi toimuda paralleelselt.

-- Küsimus 2 TPC-H-st
selgita (kulud välja) vali s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment
part, supplier, partsupp, nation, region
kus
		p_partkey = ps_partkey
		ja s_suppkey = ps_suppkey
		ja p_size = 36
		ja p_type nagu '%BRASS'
		ja s_nationkey = n_nationkey
		ja n_regionkey = r_regionkey
		ja r_name = 'AMERICA'
		ja ps_supplycost = (
			vali
			min(ps_supplycost)
			partsupp, supplier, nation, region
			kus
			p_partkey = ps_partkey
			ja s_suppkey = ps_suppkey
			ja s_nationkey = n_nationkey
			ja n_regionkey = r_regionkey
			ja r_name = 'AMERICA'
		)
järjestus s_acctbal desc, n_name, s_name, p_partkey
PIIRANG 100;
			KÜSIMUSE PLANEERIMINE
----------------------------------------------------------------------------------------------------------
 Piirang
   -&gt;  Sort
         Sort Key: supplier.s_acctbal DESC, nation.n_name, supplier.s_name, part.p_partkey
         -&gt;  Merge Join
               Merge Cond: (part.p_partkey = partsupp.ps_partkey)
               Join Filter: (partsupp.ps_supplycost = (Alluvusplaan 1))
               -&gt;  Koguge Merged
                     Plaanitud Töötajad: 4
                     -&gt;  Paralleelne Indeksi Skaneerimine kasutades <strong>part_pkey</strong> os part
                           Filter: (((p_type)::text ~~ '%BRASS'::text) JA (p_size = 36))
               -&gt;  Materjaliseerimise
                     -&gt;  Sorteerimine
                           Sort Key: partsupp.ps_partkey
                           -&gt;  Sisejõud
                                 -&gt;  Sisejõud
                                       Join Filter: (nation.n_regionkey = region.r_regionkey)
                                       -&gt;  Seq Scan on region
                                             Filter: (r_name = 'AMERICA'::bpchar)
                                       -&gt;  Hash Join
                                             Hash Cond: (supplier.s_nationkey = nation.n_nationkey)
                                             -&gt;  Seq Scan on supplier
                                             -&gt;  Hash
                                                   -&gt;  Seq Scan on nation
                                 -&gt;  Indeksi Skaneerimine kasutades idx_partsupp_suppkey on partsupp
                                       Index Cond: (ps_suppkey = supplier.s_suppkey)
               Alluvusplaan 1
                 -&gt;  Agregaat
                       -&gt;  Sisejõud
                             Join Filter: (nation_1.n_regionkey = region_1.r_regionkey)
                             -&gt;  Seq Scan on region region_1
                                   Filter: (r_name = 'AMERICA'::bpchar)
                             -&gt;  Sisejõud
                                   -&gt;  Sisejõud
                                         -&gt;  Indeksi Skaneerimine kasutades idx_partsupp_partkey on partsupp partsupp_1
                                               Index Cond: (part.p_partkey = ps_partkey)
                                         -&gt;  Indeksi Skaneerimine kasutades supplier_pkey on supplier supplier_1
                                               Index Cond: (s_suppkey = partsupp_1.ps_suppkey)
                                   -&gt;  Indeksi Skaneerimine kasutades nation_pkey on nation nation_1
                                         Index Cond: (n_nationkey = supplier_1.s_nationkey)

Noode „Merge Join” asub „Gather Merge” kohal. Seega koondamine ei kasuta paralleelset töötlemist. Kuid noode „Parallel Index Scan” aitab siiski segmendi puhul. part_pkey.

Jaotiste kaupa ühendamine

PostgreSQL 11-s jaotiste kaupa ühendamine on vaikimisi keelatud: sellel on väga kulukas planeerimine. Sarnaste jaotistega tabeleid saab ühendama jaotiste kaupa. Nii kasutab Postgres väiksemaid räsitabelid. Iga jaotise ühendamine võib olla paralleelne.

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)

Peamine on see, et jaotiste kaupa ühendamine toimub paralleelselt vaid siis, kui need jaotised on piisavalt suured.

Paralleelne lisamine — Parallel Append

Parallel Append võib kasutada erinevate plokkide jaoks erinevates tööprotsessides. Seda esineb tavaliselt UNION ALL päringutes. Puuduseks on väiksem paralleelsus, kuna iga tööprotsess töötleb vaid 1 päringut.

Käimas on 2 tööprotsessi, kuigi sisse on lülitatud 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   Parallel Append
         ->  Aggregate
               ->  Seq Scan on lineitem
                     Filter: (l_shipdate   Aggregate
               ->  Seq Scan on lineitem lineitem_1
                     Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)

Kõige olulisemad muutujad

WORK_MEM piirab mälu kogust iga protsessi jaoks, mitte ainult päringute jaoks: work_mem protsessid ühendused = väga suur mälukasutus.
max_parallel_workers_per_gather — kui palju tööprotsesse kasutatav programm kasutab paralleelse töötlemise jaoks plaanis.
max_worker_processes — kohandab töötavate protsesside koguarvu serveri CPU südamike arvu põhjal.
max_parallel_workers — sama, kuid paralleelsete tööprotsesside jaoks.

Summary

Alates versioonist 9.6 võivad paralleelne töötlemine oluliselt parandada keeruliste päringute jõudlust, mis skaneerivad palju ridu või indekseid. PostgreSQL 10-s on paralleelne töötlemine vaikimisi sisse lülitatud. Ärge unustage seda välja lülitada serverites, kus on suur OLTP koormus. Järjekorraskannid või indeksiskannid kasutavad väga palju ressursse. Kui te ei tee aruannet kogu andmestiku põhjal, võib päringute tootlikkust suurendada, lihtsalt lisades vajalikke indekseid või kasutades õiget osade jagamist.