{"id":30900,"date":"2019-10-31T21:38:02","date_gmt":"2019-10-31T18:38:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/parallelnye-zaprosy-v-postgresql\/"},"modified":"2019-10-31T21:38:02","modified_gmt":"2019-10-31T18:38:02","slug":"parallelnye-zaprosy-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql","title":{"rendered":"Paralleelsed p\u00e4ringud PostgreSQL-is","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Paralleelsed p\u00e4ringud PostgreSQL-is\" src=\"\/wp-content\/uploads\/2019\/04\/bbb4b4d3f8714bbdb9b26ada2f2253b5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nKaasaegsetes CPU-des on palju tuumasid. Aastate jooksul on rakendused teinud p\u00e4ringuid andmebaasidesse paralleelselt. Kui see on aruanne, kus k\u00fcsitakse mitmeid ridu tabelis, siis t\u00e4idetakse see kiiremini, kui kasutatakse mitut CPU-d, ja PostgreSQL-is on see v\u00f5imalik alates versioonist 9.6.<\/p>\n<p><\/p>\n<p>Funktsiooni paralleelsete p\u00e4ringute rakendamine v\u00f5ttis aega 3 aastat \u2014 p\u00e4ringute t\u00e4itmise erinevatel etappidel tuli koodi \u00fcmber kirjutada. PostgreSQL 9.6-s ilmus infrastruktuur koodi edasiste t\u00e4iustuste jaoks. J\u00e4rgmistes versioonides saavad paralleelselt t\u00e4idetud ka teised p\u00e4ringut\u00fc\u00fcbid.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"ogranicheniya\">Piirangud<\/h3>\n<p><\/p>\n<ul>\n<li>\u00c4rge l\u00fclitage paralleelset t\u00e4itmist sisse, kui k\u00f5ik tuumad on juba h\u00f5ivatud, muidu saavad teised p\u00e4ringud takistusi.<\/li>\n<li>K\u00f5ige olulisem on see, et k\u00f5rge WORK_MEM v\u00e4\u00e4rtusega paralleelne t\u00f6\u00f6tlemine kasutab palju m\u00e4lu \u2014 iga hash-\u00fchendus v\u00f5i sorteerimine kasutab m\u00e4lu mahus work_mem.<\/li>\n<li>Madala latentsusajaga OLTP p\u00e4ringute kiirus paralleelse t\u00e4itmisega ei suurene. Ja kui p\u00e4ring tagastab \u00fche rea, aeglustab paralleelne t\u00f6\u00f6tlemine seda ainult.<\/li>\n<li>Arendajad armastavad kasutada TPC-H benchmarket. V\u00f5ib-olla on teil sarnaseid p\u00e4ringuid ideaalse paralleelse t\u00e4itmise jaoks.<\/li>\n<li>Ainult SELECT-p\u00e4ringud ilma predikaatide lukustamiseta t\u00e4idetakse paralleelselt.<\/li>\n<li>M\u00f5nikord on \u00f5ige indekseerimine parem kui j\u00e4rjestikune tabeli skannimine paralleelses re\u017eiimis.<\/li>\n<li>P\u00e4ringute peatamine ja kursori kasutamine ei ole toetatud.<\/li>\n<li>Akenfunktsioonid ja sorteeritud kogumite agregaatfunktsioonid ei ole paralleelsed.<\/li>\n<li>Te ei saa midagi kasulikku I\/O koormuse osas.<\/li>\n<li>Paralleelseid sorteerimisalgoritme ei ole. Kuid sorteerimisega p\u00e4ringud v\u00f5ivad teatud aspektides toimuda paralleelselt.<\/li>\n<li>Asendage CTE (WITH ...) pesa vahekaardiga, et v\u00f5imaldada paralleelset t\u00f6\u00f6tlemist.<\/li>\n<li>Kolmandate osapoolte andmete m\u00e4hised ei toeta praegu paralleelset t\u00f6\u00f6tlemist (kuigi v\u00f5iksid!).<\/li>\n<li>FULL OUTER JOIN ei ole toetatud.<\/li>\n<li>max_rows keelab paralleelse t\u00f6\u00f6tlemise.<\/li>\n<li>Kui p\u00e4ringus on funktsioon, mis ei ole m\u00e4rgistatud kui PARALLEL SAFE, siis see k\u00e4ivitub \u00fche niidina.<\/li>\n<li>Tehingu isoleerituse tase SERIALIZABLE keelab paralleelse t\u00f6\u00f6tlemise.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"testovaya-sreda\">Testkeskkond<\/h3>\n<p><\/p>\n<p>PostgreSQL arendajad p\u00fc\u00fcdsid v\u00e4hendada TPC-H testimist p\u00e4ringute vastuste aega. Laadige test ja <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/tvondra\/pg_tpch\">kohaneda PostgreSQL-iga.<\/a><\/noindex>. See on TPC-H testi mitteametlik kasutamine \u2014 mitte andmebaaside v\u00f5i riistvara v\u00f5rdlemiseks.<\/p>\n<p><\/p>\n<ol>\n<li>Laadige alla TPC-H_Tools_v2.17.3.zip (v\u00f5i uuem versioon) <noindex><a rel=\"nofollow\" href=\"http:\/\/www.tpc.org\/tpc_documents_current_versions\/current_specifications.asp\">TPC veebisaidilt<\/a><\/noindex>.<\/li>\n<li>Nimetage makefile.suite \u00fcmber Makefile-iks ja tehke muudatused, nagu siin kirjeldatud: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/tvondra\/pg_tpch\">https:\/\/github.com\/tvondra\/pg_tpch <\/a><\/noindex>. Kompileerige kood k\u00e4sklusega make.<\/li>\n<li>Genereerige andmed: <code>.\/dbgen -s 10<\/code> loob 23 GB suuruse andmebaasi. Seda piisab, et n\u00e4ha vahet paralleelsete ja mitteparalleelsete p\u00e4ringute vahel.<\/li>\n<li>Konverteerige failid <code>tbl<\/code> \u00fches <code>csv formaati<\/code> ja <code>sed<\/code>.<\/li>\n<li>Kloonige hoidla <code>pg_tpch<\/code> ja kopeerige failid <code>csv<\/code> \u00fches <code>pg_tpch\/dss\/data<\/code>.<\/li>\n<li>Looge p\u00e4ringud k\u00e4suga <code>qgen<\/code>.<\/li>\n<li>Laadige andmed mitme k\u00e4suga <code>.\/tpch.sh<\/code>.<\/li>\n<\/ol>\n<p><\/p>\n<h3 id=\"parallelnoe-posledovatelnoe-skanirovanie\">Paralleelne j\u00e4rjestikune skaneerimine<\/h3>\n<p><\/p>\n<p>See v\u00f5ib olla kiirem mitte paralleelse lugemise t\u00f5ttu, vaid seet\u00f5ttu, et andmed on hajutatud paljude CPU tuumade vahel. Kaasaegsed operatsioonis\u00fcsteemid vahem\u00e4lustavad PostgreSQL andmefailid h\u00e4sti. Eelnev lugemine v\u00f5imaldab saada m\u00e4lust ploki, mis on suurem kui PG deemon n\u00f5uab. Seet\u00f5ttu ei ole p\u00e4ringu j\u00f5udlus piiratud ketta I\/O-ga. See kasutab CPU ts\u00fckleid, et:<\/p>\n<p><\/p>\n<ul>\n<li>lugeda ridu \u00fcksikute tabeli lehtedelt;<\/li>\n<li>v\u00f5rrelda ridade v\u00e4\u00e4rtusi ja tingimusi <code>WHERE<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<p>Tehkem lihtne p\u00e4ring <code>select<\/code>:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">tpch=# selgitada anal\u00fc\u00fcsige valikut l_quantity kui sum_qty alates lineitem, kus l_shipdate &lt;= kuup\u00e4ev &#039;1998-12-01&#039; - intervall &#039;105&#039; p\u00e4ev;\nK\u00dcSI PLANEERIMINE\n--------------------------------------------------------------------------------------------------------------------------\nSeq skannimine lineitem (kulu=0.00..1964772.00 read=58856235 laius=5) (tegelik aeg=0.014..16951.669 read=58839715 ts\u00fcklites=1)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::aeg ilma ajav\u00f6\u00f6ndita)\nFilteri t\u00f5ttu eemaldatud read: 1146337\nPlaneerimise aeg: 0.203 ms\nT\u00e4ideviimise aeg: 19035.100 ms<\/code><\/pre>\n<p><\/p>\n<p>J\u00e4rjekorraskannimine annab liiga palju read ilma agregatsioonita, mist\u00f5ttu p\u00e4ring k\u00e4itatakse \u00fche CPU tuuma poolt.<\/p>\n<p><\/p>\n<p>Kui lisada <code>SUM()<\/code>, on n\u00e4ha, et kaks t\u00f6\u00f6protsessi aitavad p\u00e4ringut kiirendada:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">selgitada anal\u00fc\u00fcsige valikut sum(l_quantity) kui sum_qty alates lineitem, kus l_shipdate &lt;= kuup\u00e4ev &#039;1998-12-01&#039; - intervall &#039;105&#039; p\u00e4ev;\nK\u00dcSI PLANEERIMINE\n----------------------------------------------------------------------------------------------------------------------------------------------------\nL\u00f5peta Aggregate (kulu=1589702.14..1589702.15 read=1 laius=32) (tegelik aeg=8553.365..8553.365 read=1 ts\u00fcklites=1)\n-&gt; Kogumise (kulu=1589701.91..1589702.12 read=2 laius=32) (tegelik aeg=8553.241..8555.067 read=3 ts\u00fcklites=1)\nPlaanitavad t\u00f6\u00f6tajad: 2\nK\u00e4ivitamisprotsessid: 2\n-&gt; Osaline Aggregate (kulu=1588701.91..1588701.92 read=1 laius=32) (tegelik aeg=8547.546..8547.546 read=1 ts\u00fcklites=3)\n-&gt; Paralleelne Seq Scan lineitem (kulu=0.00..1527393.33 read=24523431 laius=5) (tegelik aeg=0.038..5998.417 read=19613238 ts\u00fcklites=3)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::aeg ilma ajav\u00f6\u00f6ndita)\nFilteri t\u00f5ttu eemaldatud read: 382112\nPlaneerimise aeg: 0.241 ms\nT\u00e4ideviimise aeg: 8555.131 ms<\/code><\/pre>\n<p><\/p>\n<h3 id=\"parallelnaya-agregaciya\">Paralleelne agregatsioon<\/h3>\n<p><\/p>\n<p>Nood &#171;Parallel Seq Scan&#187; toob osaliselt agragutud read. Nood &#171;Partial Aggregate&#187; l\u00f5ikab need read v\u00e4lja, kasutades <code>SUM()<\/code>. L\u00f5puks kogub SUM-kalkulaator igast t\u00f6\u00f6protsessist noodis &#171;Gather&#187;.<\/p>\n<p><\/p>\n<p>L\u00f5plik tulemus arvutatakse noodis &#171;Finalize Aggregate&#187;. Kui teil on oma agragutifunktsioonid, \u00e4rge unustage t\u00e4histada neid kui &#171;parallel safe&#187;.<\/p>\n<p><\/p>\n<h3 id=\"kolichestvo-rabochih-processov\">T\u00f6\u00f6protsesside arv<\/h3>\n<p><\/p>\n<p>T\u00f6\u00f6protsesside arvu saab suurendada ilma serverit taask\u00e4ivitamata:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">selgitada anal\u00fc\u00fcsige valikut sum(l_quantity) kui sum_qty alates lineitem, kus l_shipdate &lt;= kuup\u00e4ev &#039;1998-12-01&#039; - intervall &#039;105&#039; p\u00e4ev;\nK\u00dcSI PLANEERIMINE\n----------------------------------------------------------------------------------------------------------------------------------------------------\nL\u00f5peta Aggregate (kulu=1589702.14..1589702.15 read=1 laius=32) (tegelik aeg=8553.365..8553.365 read=1 ts\u00fcklites=1)\n-&gt; Kogumise (kulu=1589701.91..1589702.12 read=2 laius=32) (tegelik aeg=8553.241..8555.067 read=3 ts\u00fcklites=1)\nPlaanitavad t\u00f6\u00f6tajad: 2\nK\u00e4ivitamisprotsessid: 2\n-&gt; Osaline Aggregate (kulu=1588701.91..1588701.92 read=1 laius=32) (tegelik aeg=8547.546..8547.546 read=1 ts\u00fcklites=3)\n-&gt; Paralleelne Seq Scan lineitem (kulu=0.00..1527393.33 read=24523431 laius=5) (tegelik aeg=0.038..5998.417 read=19613238 ts\u00fcklites=3)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::aeg ilma ajav\u00f6\u00f6ndita)\nFilteri t\u00f5ttu eemaldatud read: 382112\nPlaneerimise aeg: 0.241 ms\nT\u00e4ideviimise aeg: 8555.131 ms<\/code><\/pre>\n<p><\/p>\n<p>Mis siin toimub? T\u00f6\u00f6protsesside arv on kahekordistunud, kuid p\u00e4ring on ainult 1,6599 korda kiirem. Arvutused on huvitavad. Meil oli 2 t\u00f6\u00f6protsessi ja 1 liider. Muudatuse j\u00e4rel on tulemuseks 4+1.<\/p>\n<p><\/p>\n<p>Meie maksimaalne kiirus parallel t\u00f6\u00f6tlemiselt: 5\/3 = 1,66 (6) korda.<\/p>\n<p><\/p>\n<h2 id=\"kak-eto-rabotaet\">Kuidas see t\u00f6\u00f6tab?<\/h2>\n<p><\/p>\n<h3 id=\"processy\">Protsessid<\/h3>\n<p><\/p>\n<p>P\u00e4ringu t\u00e4itmine algab alati liidris. Liider teeb k\u00f5ik mitte-paralleelsed ja osa paralleelseid t\u00f6\u00f6tlemisi. Teised protsessid, mis t\u00e4idavad samu p\u00e4ringuid, nimetatakse t\u00f6\u00f6protsessideks. Paralleelne t\u00f6\u00f6tlemine kasutab infrastruktuuri <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/bgworker.html\">d\u00fcnaamiliste taustat\u00f6\u00f6protsesside<\/a><\/noindex> (versioonist 9.4). Kuna teised PostgreSQL osad kasutavad protsesse, mitte l\u00f5ime, v\u00f5is p\u00e4ringu t\u00e4itmine kolme t\u00f6\u00f6protsessiga olla neli korda kiirem kui traditsiooniline t\u00f6\u00f6tlemine.<\/p>\n<p><\/p>\n<h3 id=\"vzaimodeystvie\">Koostoime<\/h3>\n<p><\/p>\n<p>T\u00f6\u00f6protsessid suhtlevad liidri ehk peaprotsessiga s\u00f5numij\u00e4rgijate kaudu (\u00fchisest m\u00e4lust). Igal protsessil on kaks j\u00e4rjekorda: vigade ja tupikute jaoks.<\/p>\n<p><\/p>\n<h3 id=\"skolko-nuzhno-rabochih-processov\">Kui palju t\u00f6\u00f6protsesse on vajalik?<\/h3>\n<p><\/p>\n<p>Minimaalne piirang m\u00e4\u00e4ratakse parameetriga <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER\"><code>max_parallel_workers_per_gather<\/code><\/a><\/noindex>. Seej\u00e4rel v\u00f5tab p\u00e4ringute t\u00e4itja t\u00f6\u00f6protsessid basseinist, mille suurust piirab parameeter <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES\"><code>max_parallel_workers size<\/code><\/a><\/noindex>. Viimane piirang on <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES\"><code>max_worker_processes<\/code><\/a><\/noindex>, mis t\u00e4histab taustaprotsesside koguarvu.<\/p>\n<p><\/p>\n<p>Kui t\u00f6\u00f6protsessi eraldamine eba\u00f5nnestub, toimub t\u00f6\u00f6tlemine \u00fches protsessis.<\/p>\n<p><\/p>\n<p>P\u00e4ringute planeerija v\u00f5ib v\u00e4hendada t\u00f6\u00f6protsesside arvu s\u00f5ltuvalt tabeli v\u00f5i indeksi suurusest. Selle jaoks on olemas parameetrid <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/runtime-config-query.html#GUC-MIN-PARALLEL-TABLE-SCAN-SIZE\"><code>min_parallel_table_scan_size<\/code><\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/runtime-config-query.html#GUC-MIN-PARALLEL-INDEX-SCAN-SIZE\"><code>min_parallel_index_scan_size<\/code><\/a><\/noindex>.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">set min_parallel_table_scan_size='8MB'\n8MB tabel =&gt; 1 t\u00f6\u00f6taja\n24MB tabel =&gt; 2 t\u00f6\u00f6tajat\n72MB tabel =&gt; 3 t\u00f6\u00f6tajat\nx =&gt; log(x \/ min_parallel_table_scan_size) \/ log(3) + 1 t\u00f6\u00f6taja<\/code><\/pre>\n<p><\/p>\n<p>Iga kord, kui tabel on kolm korda suurem kui <code>min_parallel_(index|table)_scan_size<\/code>, Postgres lisab t\u00f6\u00f6voo. T\u00f6\u00f6voogude arv ei p\u00f5hine kuludel. Ringline s\u00f5ltuvus raskendab keerukate rakenduste loomist. Selle asemel kasutab ajakava lihtsaid reegleid.<\/p>\n<p><\/p>\n<p>Praktikas ei sobi need reeglid alati tootmiseks, seet\u00f5ttu on v\u00f5imalik muuta t\u00f6\u00f6voogude arvu konkreetse tabeli jaoks: ALTER TABLE \u2026 SET (<code>parallel_workers = N<\/code>).<\/p>\n<p><\/p>\n<h3 id=\"pochemu-parallelnaya-obrabotka-ne-ispolzuetsya\">Miks paralleelset t\u00f6\u00f6tlemist ei kasutata?<\/h3>\n<p><\/p>\n<p>Pika piirangute nimekirja k\u00f5rval on olemas ka kulude kontrollid:<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/runtime-config-query.html#GUC-PARALLEL-SETUP-COST\"><code>parallel_setup_cost<\/code><\/a><\/noindex> \u2014 et v\u00e4ltida paralleelset t\u00f6\u00f6tlemist l\u00fchikeste p\u00e4ringute jaoks. See parameeter hindab m\u00e4lu ettevalmistamise, protsessi k\u00e4ivitamise ja esialgse andmevahetuse aega.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/runtime-config-query.html#GUC-PARALLEL-TUPLE-COST\"><code>parallel_tuple_cost<\/code><\/a><\/noindex>: juhipoolne suhtlemine t\u00f6\u00f6dega v\u00f5ib pikendada proportsionaalselt t\u00f6\u00f6protsesside kinnitusproovide arvuga. See parameeter arvutab andmevahetuse kulud.<\/p>\n<p><\/p>\n<h3 id=\"soedineniya-vlozhennyh-ciklov--nested-loop-join\">Sisemised ts\u00fcklilised \u00fchendused \u2014 Nested Loop Join<\/h3>\n<p><\/p>\n<pre><code class=\"plaintext\">PostgreSQL 9.6+ \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c \u0432\u043b\u043e\u0436\u0435\u043d\u043d\u044b\u0435 \u0446\u0438\u043a\u043b\u044b \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u043e \u2014 \u044d\u0442\u043e \u043f\u0440\u043e\u0441\u0442\u0430\u044f \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u044f.\n\nexplain (costs off) select c_custkey, count(o_orderkey)\n                from    customer left outer join orders on\n                                c_custkey = o_custkey and o_comment not like '%special%deposits%'\n                group by c_custkey;\n                                      QUERY PLAN\n--------------------------------------------------------------------------------------\n Finalize GroupAggregate\n   Group Key: customer.c_custkey\n   -&gt;  Gather Merge\n         Workers Planned: 4\n         -&gt;  Partial GroupAggregate\n               Group Key: customer.c_custkey\n               -&gt;  Nested Loop Left Join\n                     -&gt;  Parallel Index Only Scan using customer_pkey on customer\n                     -&gt;  Index Scan using idx_orders_custkey on orders\n                           Index Cond: (customer.c_custkey = o_custkey)\n                           Filter: ((o_comment)::text !~~ '%special%deposits%'::text)<\/code><\/pre>\n<p><\/p>\n<p>Kogumine toimub viimases etapis, nii et Nested Loop Left Join on paralleelne operatsioon. Parallel Index Only Scan ilmus alles versioonis 10. See t\u00f6\u00f6tab sarnaselt paralleelsele j\u00e4rjestikusele skannimisele. Tingimus <code>c_custkey = o_custkey<\/code> loob \u00fche tellimuse iga kliendi rea kohta. Nii et see ei ole paralleelne.<\/p>\n<p><\/p>\n<h3 id=\"hesh-soedinenie--hash-join\">Hash Join<\/h3>\n<p><\/p>\n<p>Iga t\u00f6\u00f6protsess loob oma r\u00e4sitabeli kuni PostgreSQL 11. Ja kui neid protsesse on rohkem kui neli, siis j\u00f5udlus ei parane. Uues versioonis on r\u00e4sitabel \u00fchine. Iga t\u00f6\u00f6protsess v\u00f5ib kasutada WORK_MEM-i, et luua r\u00e4sitabel.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">valige\n        l_shipmode,\n        summa(juhul\n                kui o_orderpriority = '1-URGENT'\n                        v\u00f5i o_orderpriority = '2-HIGH'\n                        siis 1\n                muidu 0\n        l\u00f5pp) kui high_line_count,\n        summa(juhul\n                kui o_orderpriority &lt;&gt; '1-URGENT'\n                        ja o_orderpriority &lt;&gt; '2-HIGH'\n                        siis 1\n                muidu 0\n        l\u00f5pp) kui low_line_count\nfrom\n        orders,\n        lineitem\nkus\n        o_orderkey = l_orderkey\n        ja l_shipmode in ('MAIL', 'AIR')\n        ja l_commitdate &lt; l_receiptdate\n        ja l_shipdate &lt; l_commitdate\n        ja l_receiptdate &gt;= date '1996-01-01'\n        ja l_receiptdate &lt; date '1996-01-01' + interval '1' aasta\ngrupi j\u00e4rgi\n        l_shipmode\nj\u00e4rjekorras\n        l_shipmode\nPIIRANG 1;\n                                                                                                                                    K\u00dcSI PLAA\n-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n Piirang  (kulu=1964755.66..1964961.44 read=1 laius=27) (reaalne aeg=7579.592..7922.997 read=1 ts\u00fcklit=1)\n   -&gt;  L\u00f5peta GroupAggregate  (kulu=1964755.66..1966196.11 read=7 laius=27) (reaalne aeg=7579.590..7579.591 read=1 ts\u00fcklit=1)\n         Grupp v\u00f5tme: lineitem.l_shipmode\n         -&gt;  Koosta Merge  (kulu=1964755.66..1966195.83 read=28 laius=27) (reaalne aeg=7559.593..7922.319 read=6 ts\u00fcklit=1)\n               Plaanitud T\u00f6\u00f6tajad: 4\n               K\u00e4ivitatud T\u00f6\u00f6tajad: 4\n               -&gt;  Osaline GroupAggregate  (kulu=1963755.61..1965192.44 read=7 laius=27) (reaalne aeg=7548.103..7564.592 read=2 ts\u00fcklit=5)\n                     Grupp v\u00f5tme: lineitem.l_shipmode\n                     -&gt;  Sorteeri  (kulu=1963755.61..1963935.20 read=71838 laius=27) (reaalne aeg=7530.280..7539.688 read=62519 ts\u00fcklit=5)\n                           Sorteeri v\u00f5tme: lineitem.l_shipmode\n                           Sorteerimise meetod: v\u00e4line \u00fchine  Disk: 2304kB\n                           T\u00f6\u00f6taja 0:  Sorteerimise meetod: v\u00e4line \u00fchine  Disk: 2064kB\n                           T\u00f6\u00f6taja 1:  Sorteerimise meetod: v\u00e4line \u00fchine  Disk: 2384kB\n                           T\u00f6\u00f6taja 2:  Sorteerimise meetod: v\u00e4line \u00fchine  Disk: 2264kB\n                           T\u00f6\u00f6taja 3:  Sorteerimise meetod: v\u00e4line \u00fchine  Disk: 2336kB\n                           -&gt;  Paralleelne Hash Join  (kulu=382571.01..1957960.99 read=71838 laius=27) (reaalne aeg=7036.917..7499.692 read=62519 ts\u00fcklit=5)\n                                 Hash Cond: (lineitem.l_orderkey = orders.o_orderkey)\n                                 -&gt;  Paralleelne Seq Scan lineitem  (kulu=0.00..1552386.40 read=71838 laius=19) (reaalne aeg=0.583..4901.063 read=62519 ts\u00fcklit=5)\n                                       Filter: ((l_shipmode = ANY ('{MAIL,AIR}'::bpchar[])) JA (l_commitdate &lt; l_receiptdate) JA (l_shipdate &lt; l_commitdate) JA (l_receiptdate &gt;= '1996-01-01'::date) JA (l_receiptdate &lt; '1997-01-01 00:00:00'::timestamp without time zone))\n                                       Readud read Filteri kaudu: 11934691\n                                 -&gt;  Paralleelne Hash  (kulu=313722.45..313722.45 read=3750045 laius=20) (reaalne aeg=2011.518..2011.518 read=3000000 ts\u00fcklit=5)\n                                       Kasti: 65536  Batchid: 256  M\u00e4lu kasutamine: 3840kB\n                                       -&gt;  Paralleelne Seq Scan orders  (kulu=0.00..313722.45 read=3750045 laius=20) (reaalne aeg=0.029..995.948 read=3000000 ts\u00fcklit=5)\n Planeerimise aeg: 0.977 ms\n T\u00e4itmise aeg: 7923.770 ms<\/code><\/pre>\n<p><\/p>\n<p>T\u00f5e 12 TPC-H-i j\u00e4rgi illustreerib paralleelset hash-\u00fchendust. Iga t\u00f6\u00f6protsess osaleb \u00fchise hash-tabeli loomises.<\/p>\n<p><\/p>\n<h3 id=\"soedinenie-sliyaniem--merge-join\">\u00dchendus liitmisega \u2014 Merge Join<\/h3>\n<p><\/p>\n<p>Liitmise \u00fchendamine on iseenesest paralleelne. \u00c4rge muretsege, kui see on p\u00e4ringu viimane etapp \u2014 see v\u00f5ib olla siiski paralleelne.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">-- K&Uuml;SIMUS 2 TPC-H-st\nselgita (kulud v&auml;lja) vali s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment\npart, supplier, partsupp, nation, region\nkus\n        p_partkey = ps_partkey\n        ja s_suppkey = ps_suppkey\n        ja p_size = 36\n        ja p_type nagu &#039;%BRASS&#039;\n        ja s_nationkey = n_nationkey\n        ja n_regionkey = r_regionkey\n        ja r_name = &#039;AMERICA&#039;\n        ja ps_supplycost = (\n                vali\n                        min(ps_supplycost)\n                partsupp, supplier, nation, region\n                kus\n                        p_partkey = ps_partkey\n                        ja s_suppkey = ps_suppkey\n                        ja s_nationkey = n_nationkey\n                        ja n_regionkey = r_regionkey\n                        ja r_name = &#039;AMERICA&#039;\n        )\nj&auml;rjesta s_acctbal j&auml;rsult, n_name, s_name, p_partkey\nPIIR 100;\n                                                K&Uuml;SIMUSE PLAAN\n----------------------------------------------------------------------------------------------------------\n Piir\n   -&amp;gt;  Sort\n         Sortimise v&otilde;ti: supplier.s_acctbal DESC, nation.n_name, supplier.s_name, part.p_partkey\n         -&amp;gt;  Merge Join\n               &Uuml;henduse tingimus: (part.p_partkey = partsupp.ps_partkey)\n               &Uuml;henduse filter: (partsupp.ps_supplycost = (SubPlan 1))\n               -&amp;gt;  Kogum Merge\n                     Planeeritud t&ouml;&ouml;tajaid: 4\n                     -&amp;gt;  Paralleelne indeksiskannimine kasutades &lt;strong&gt;part_pkey&lt;\/strong&gt; osa\n                           Filter: (((p_type)::text ~~ &#039;%BRASS&#039;::text) AND (p_size = 36))\n               -&amp;gt;  Materialize\n                     -&amp;gt;  Sort\n                           Sort Key: partsupp.ps_partkey\n                           -&amp;gt;  Nested Loop\n                                 -&amp;gt;  Nested Loop\n                                       Join Filter: (nation.n_regionkey = region.r_regionkey)\n                                       -&amp;gt;  Seq Scan on region\n                                             Filter: (r_name = &#039;AMERICA&#039;::bpchar)\n                                       -&amp;gt;  Hash Join\n                                             Hash Cond: (supplier.s_nationkey = nation.n_nationkey)\n                                             -&amp;gt;  Seq Scan on supplier\n                                             -&amp;gt;  Hash\n                                                   -&amp;gt;  Seq Scan on nation\n                                 -&amp;gt;  Index Scan using idx_partsupp_suppkey on partsupp\n                                       Index Cond: (ps_suppkey = supplier.s_suppkey)\n               SubPlan 1\n                 -&amp;gt;  Aggregate\n                       -&amp;gt;  Nested Loop\n                             Join Filter: (nation_1.n_regionkey = region_1.r_regionkey)\n                             -&amp;gt;  Seq Scan on region region_1\n                                   Filter: (r_name = &#039;AMERICA&#039;::bpchar)\n                             -&amp;gt;  Nested Loop\n                                   -&amp;gt;  Nested Loop\n                                         -&amp;gt;  Index Scan using idx_partsupp_partkey on partsupp partsupp_1\n                                               Index Cond: (part.p_partkey = ps_partkey)\n                                         -&amp;gt;  Index Scan using supplier_pkey on supplier supplier_1\n                                               Index Cond: (s_suppkey = partsupp_1.ps_suppkey)\n                                   -&amp;gt;  Index Scan using nation_pkey on nation nation_1\n                                         Index Cond: (n_nationkey = supplier_1.s_nationkey)<\/code><\/pre>\n<p><\/p>\n<p>Nood &#171;Merge Join&#187; asub &#171;Gather Merge&#187; kohal. Seega ei kasuta liitmine paralleelset t\u00f6\u00f6tlemist. Kuid nood &#171;Parallel Index Scan&#187; aitab ikkagi segmenti. <code>part_pkey<\/code>.<\/p>\n<p><\/p>\n<h3 id=\"soedinenie-po-sekciyam\">Sektsioonide kaupa \u00fchendamine<\/h3>\n<p><\/p>\n<p>PostgreSQL 11-s <noindex><a rel=\"nofollow\" href=\"http:\/\/ashutoshpg.blogspot.com\/2017\/12\/partition-wise-joins-divide-and-conquer.html\">sektsioonide kaupa \u00fchendamine<\/a><\/noindex> on vaikimisi keelatud: sellel on v\u00e4ga kulukas planeerimine. Sarnase sektsiooniga tabelid saab \u00fchendada sektsioonide kaupa. Nii kasutab Postgres v\u00e4iksemaid hash-tabeleid. Iga sektsioonide vaheline \u00fchendamine v\u00f5ib olla paralleelne.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">tpch=# set enable_partitionwise_join=t;\ntpch=# explain (costs off) select * from prt1 t1, prt2 t2\nwhere t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;\n                    QUERY PLAN\n---------------------------------------------------\n Append\n   -&gt;  Hash Join\n         Hash Cond: (t2.b = t1.a)\n         -&gt;  Seq Scan on prt2_p1 t2\n               Filter: ((b &gt;= 0) AND (b   Hash\n               -&gt;  Seq Scan on prt1_p1 t1\n                     Filter: (b = 0)\n   -&gt;  Hash Join\n         Hash Cond: (t2_1.b = t1_1.a)\n         -&gt;  Seq Scan on prt2_p2 t2_1\n               Filter: ((b &gt;= 0) AND (b   Hash\n               -&gt;  Seq Scan on prt1_p2 t1_1\n                     Filter: (b = 0)\ntpch=# set parallel_setup_cost = 1;\ntpch=# set parallel_tuple_cost = 0.01;\ntpch=# explain (costs off) select * from prt1 t1, prt2 t2\nwhere t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;\n                        QUERY PLAN\n-----------------------------------------------------------\n Gather\n   Workers Planned: 4\n   -&gt;  Parallel Append\n         -&gt;  Parallel Hash Join\n               Hash Cond: (t2_1.b = t1_1.a)\n               -&gt;  Parallel Seq Scan on prt2_p2 t2_1\n                     Filter: ((b &gt;= 0) AND (b   Parallel Hash\n                     -&gt;  Parallel Seq Scan on prt1_p2 t1_1\n                           Filter: (b = 0)\n         -&gt;  Parallel Hash Join\n               Hash Cond: (t2.b = t1.a)\n               -&gt;  Parallel Seq Scan on prt2_p1 t2\n                     Filter: ((b &gt;= 0) AND (b   Parallel Hash\n                     -&gt;  Parallel Seq Scan on prt1_p1 t1\n                           Filter: (b = 0)<\/code><\/pre>\n<p><\/p>\n<p>Peamine, sektsioonide vahelised \u00fchendused on paralleelsed ainult siis, kui need sektsioonid on piisavalt suured.<\/p>\n<p><\/p>\n<h3 id=\"parallelnoe-dopolnenie--parallel-append\">Paralleelne lisamine \u2014 Parallel Append<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/parallel-plans.html#PARALLEL-APPEND\">Parallel Append<\/a><\/noindex> v\u00f5ib kasutada erinevates t\u00f6\u00f6voogudes erinevate plokkide asemel. See juhtub tavaliselt UNION ALL p\u00e4ringutega. Puuduseks on v\u00e4hem paralleelsust, kuna iga t\u00f6\u00f6protsess t\u00f6\u00f6tleb ainult \u00fchte p\u00e4ringut.<\/p>\n<p><\/p>\n<p>Siin on k\u00e4ivitatud 2 t\u00f6\u00f6protsessi, kuigi on aktiveeritud 4.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">tpch=# explain (costs off) select sum(l_quantity) as sum_qty from lineitem where l_shipdate &lt;= date &#039;1998-12-01&#039; - interval &#039;105&#039; day union all select sum(l_quantity) as sum_qty from lineitem where l_shipdate   Paralleelne lisamine\n         -&gt;  Agregaat\n               -&gt;  Seq Scan on lineitem\n                     Filter: (l_shipdate   Agregaat\n               -&gt;  Seq Scan on lineitem lineitem_1\n                     Filter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::timestamp without time zone)<\/code><\/pre>\n<p><\/p>\n<h3 id=\"samye-vazhnye-peremennye\">K\u00f5ige olulisemad muutujad<\/h3>\n<p><\/p>\n<ul>\n<li>WORK_MEM piirdab m\u00e4lu mahtu iga protsessi jaoks, mitte ainult p\u00e4ringute jaoks: work_mem <em> protsessid <\/em> \u00fchendused = v\u00e4ga suur m\u00e4lu.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER\"><code>max_parallel_workers_per_gather<\/code><\/a><\/noindex> \u2014 kui palju t\u00f6\u00f6protsesse programm kasutab paralleelse t\u00f6\u00f6tlemise jaoks plaanist.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES\"><code>max_worker_processes<\/code><\/a><\/noindex> \u2014 kohandab t\u00f6\u00f6protsesside \u00fcldarvu serveri CPU s\u00fcdamete arvu j\u00e4rgi.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES\"><code>max_parallel_workers<\/code><\/a><\/noindex> \u2014 sama, kuid paralleelsete t\u00f6\u00f6protsesside jaoks.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"itogi\">Kokkuv\u00f5te<\/h3>\n<p><\/p>\n<p>Alates versioonist 9.6 v\u00f5ib paralleelne t\u00f6\u00f6tlemine oluliselt parandada keeruliste p\u00e4ringute j\u00f5udlust, mis skannivad palju ridu v\u00f5i indekseid. PostgreSQL 10-s on paralleelne t\u00f6\u00f6tlemine vaikimisi sisse l\u00fclitatud. \u00c4rge unustage seda v\u00e4lja l\u00fclitada OLTP-suurte t\u00f6\u00f6koormuste serverites. J\u00e4rjekindlad skannimised v\u00f5i indeksi skannimised tarbivad v\u00e4ga palju ressursse. Kui te ei tee aruannet kogu andmestiku ulatuses, on p\u00e4ringute t\u00f5husamatel saavutamiseks lihtsalt vaja lisada puuduvad indeksid v\u00f5i kasutada \u00f5iget jagamist.<\/p>\n<p><\/p>\n<h3 id=\"ssylki\">Lingid<\/h3>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/how-parallel-query-works.html\">https:\/\/www.postgresql.org\/docs\/11\/how-parallel-query-works.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/parallel-plans.html\">https:\/\/www.postgresql.org\/docs\/11\/parallel-plans.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/ashutoshpg.blogspot.com\/2017\/12\/partition-wise-joins-divide-and-conquer.html\">http:\/\/ashutoshpg.blogspot.com\/2017\/12\/partition-wise-joins-divide-and-conquer.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/rhaas.blogspot.com\/2016\/04\/postgresql-96-with-parallel-query-vs.html\">http:\/\/rhaas.blogspot.com\/2016\/04\/postgresql-96-with-parallel-query-vs.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/amitkapila16.blogspot.com\/2015\/11\/parallel-sequential-scans-in-play.html\">http:\/\/amitkapila16.blogspot.com\/2015\/11\/parallel-sequential-scans-in-play.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/write-skew.blogspot.com\/2018\/01\/parallel-hash-for-postgresql.html\">https:\/\/write-skew.blogspot.com\/2018\/01\/parallel-hash-for-postgresql.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/rhaas.blogspot.com\/2017\/03\/parallel-query-v2.html\">http:\/\/rhaas.blogspot.com\/2017\/03\/parallel-query-v2.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/blog.2ndquadrant.com\/parallel-monster-benchmark\/\">https:\/\/blog.2ndquadrant.com\/parallel-monster-benchmark\/<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/blog.2ndquadrant.com\/parallel-aggregate\/\">https:\/\/blog.2ndquadrant.com\/parallel-aggregate\/<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.depesz.com\/2018\/02\/12\/waiting-for-postgresql-11-support-parallel-btree-index-builds\/\">https:\/\/www.depesz.com\/2018\/02\/12\/waiting-for-postgresql-11-support-parallel-btree-index-builds\/<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/jWIOZzezbb8\">Paralleelsus PostgreSQL 11-is<\/a><\/noindex><\/li>\n<\/ul>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/446706\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0426\u041f \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u044f\u0434\u0435\u0440. \u0413\u043e\u0434\u0430\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0441\u044b\u043b\u0430\u043b\u0438 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0432 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u043e. \u0415\u0441\u043b\u0438 \u044d\u0442\u043e \u043e\u0442\u0447\u0435\u0442\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 \u043a\u043e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0443 \u0441\u0442\u0440\u043e\u043a \u0432 \u0442\u0430\u0431\u043b\u0438\u0446\u0435, \u043e\u043d \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043a\u043e\u0433\u0434\u0430 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u0443\u0435\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0426\u041f, \u0438 \u0432 PostgreSQL \u044d\u0442\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043d\u0430\u0447\u0438\u043d\u0430\u044f \u0441 \u0432\u0435\u0440\u0441\u0438\u0438 9.6. \u041f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u043b\u043e\u0441\u044c 3 \u0433\u043e\u0434\u0430, \u0447\u0442\u043e\u0431\u044b \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u044e \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u044b\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u2014 \u043f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u0430\u0442\u044c \u043a\u043e\u0434 \u043d\u0430 \u0440\u0430\u0437\u043d\u044b\u0445 \u044d\u0442\u0430\u043f\u0430\u0445 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22879,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30900","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0426\u041f \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u044f\u0434\u0435\u0440. \u0413\u043e\u0434\u0430\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0441\u044b\u043b\u0430\u043b\u0438 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0432 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u043e. \u0415\u0441\u043b\u0438 \u044d\u0442\u043e \u043e\u0442\u0447\u0435\u0442\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 \u043a\u043e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0443 \u0441\u0442\u0440\u043e\u043a \u0432 \u0442\u0430\u0431\u043b\u0438\u0446\u0435, \u043e\u043d \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043a\u043e\u0433\u0434\u0430 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u0443\u0435\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0426\u041f, \u0438 \u0432 PostgreSQL \u044d\u0442\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043d\u0430\u0447\u0438\u043d\u0430\u044f \u0441 \u0432\u0435\u0440\u0441\u0438\u0438 9.6. \u041f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u043b\u043e\u0441\u044c 3 \u0433\u043e\u0434\u0430, \u0447\u0442\u043e\u0431\u044b \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u044e \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u044b\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u2014 \u043f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u0430\u0442\u044c \u043a\u043e\u0434 \u043d\u0430 \u0440\u0430\u0437\u043d\u044b\u0445 \u044d\u0442\u0430\u043f\u0430\u0445 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u044b\u0435 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0432 PostgreSQL | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0426\u041f \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u044f\u0434\u0435\u0440. \u0413\u043e\u0434\u0430\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0441\u044b\u043b\u0430\u043b\u0438 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0432 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u043e. \u0415\u0441\u043b\u0438 \u044d\u0442\u043e \u043e\u0442\u0447\u0435\u0442\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 \u043a\u043e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0443 \u0441\u0442\u0440\u043e\u043a \u0432 \u0442\u0430\u0431\u043b\u0438\u0446\u0435, \u043e\u043d \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043a\u043e\u0433\u0434\u0430 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u0443\u0435\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0426\u041f, \u0438 \u0432 PostgreSQL \u044d\u0442\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043d\u0430\u0447\u0438\u043d\u0430\u044f \u0441 \u0432\u0435\u0440\u0441\u0438\u0438 9.6. \u041f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u043b\u043e\u0441\u044c 3 \u0433\u043e\u0434\u0430, \u0447\u0442\u043e\u0431\u044b \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u044e \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u044b\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u2014 \u043f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u0430\u0442\u044c \u043a\u043e\u0434 \u043d\u0430 \u0440\u0430\u0437\u043d\u044b\u0445 \u044d\u0442\u0430\u043f\u0430\u0445 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:38:02+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:38:02+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Paralleelsed p\u00e4ringud PostgreSQL-is | ProHoster","description":"Kaasaegsetes protsessorites on palju tuumasid. Aastate jooksul on rakendused saatnud p\u00e4ringuid andmebaasidele paralleelselt. Kui see on aruandep\u00e4ring paljudest ridadest tabelis, siis toimub see kiiremini mitme protsessori kasutamisel ning PostgreSQL-is on see v\u00f5imalik alates versioonist 9.6. Paralleelsete p\u00e4ringute funktsiooni rakendamiseks kulus 3 aastat \u2014 tuli kirjutada kood erinevates t\u00e4itmisetappides \u00fcmber.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u044b\u0435 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0432 PostgreSQL | ProHoster","og:description":"\u0412 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0426\u041f \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u044f\u0434\u0435\u0440. \u0413\u043e\u0434\u0430\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0441\u044b\u043b\u0430\u043b\u0438 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0432 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u043e. \u0415\u0441\u043b\u0438 \u044d\u0442\u043e \u043e\u0442\u0447\u0435\u0442\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 \u043a\u043e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0443 \u0441\u0442\u0440\u043e\u043a \u0432 \u0442\u0430\u0431\u043b\u0438\u0446\u0435, \u043e\u043d \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043a\u043e\u0433\u0434\u0430 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u0443\u0435\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0426\u041f, \u0438 \u0432 PostgreSQL \u044d\u0442\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043d\u0430\u0447\u0438\u043d\u0430\u044f \u0441 \u0432\u0435\u0440\u0441\u0438\u0438 9.6. \u041f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u043b\u043e\u0441\u044c 3 \u0433\u043e\u0434\u0430, \u0447\u0442\u043e\u0431\u044b \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u044e \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u044b\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u2014 \u043f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u0430\u0442\u044c \u043a\u043e\u0434 \u043d\u0430 \u0440\u0430\u0437\u043d\u044b\u0445 \u044d\u0442\u0430\u043f\u0430\u0445 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:38:02+00:00","article:modified_time":"2019-10-31T18:38:02+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30900","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 03:34:04","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:27:06","updated":"2026-01-21 03:34:04","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/30900","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=30900"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/30900\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/22879"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=30900"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=30900"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=30900"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}