{"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 protsessorites on v\u00e4ga palju s\u00fcdamikke. Aastaid on rakendused andmebaasidele p\u00e4ringute saatmiseks t\u00f6\u00f6tanud paralleelselt. Kui see on aruande p\u00e4ring, mis h\u00f5lmab mitmeid tabeleid, siis toimub see kiiremini, kui kasutatakse mitut protsessorit, ja PostgreSQL-is on see v\u00f5imalik alates versioonist 9.6.<\/p>\n<p><\/p>\n<p>Kulutasime 3 aastat paralleelsete p\u00e4ringute funktsiooni rakendamisele \u2014 tuli kirjutada kood \u00fcmber erinevatel p\u00e4ringu t\u00e4itmise etappidel. PostgreSQL 9.6 t\u00f5i kaasa infrastruktuuri koodi edasiseks t\u00e4iustamiseks. Hilisemates versioonides saavad ka teised p\u00e4ringut\u00fc\u00fcbid t\u00f6\u00f6tada paralleelselt.<\/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 protsessoris\u00fcdamikud on juba h\u00f5ivatud, vastasel juhul aeglustavad teised p\u00e4ringud.<\/li>\n<li>Peamine asi on see, et k\u00f5rge WORK_MEM v\u00e4\u00e4rtusega paralleelne t\u00f6\u00f6tlemine kasutab palju m\u00e4lu \u2014 iga hash-\u00fchendus v\u00f5i sortimine vajab m\u00e4lu vastavalt work_mem-i mahule.<\/li>\n<li>OLTP p\u00e4ringud, millel on madal latentsus, ei saa paralleelse t\u00e4itmisega kiiremaks muutuda. Ja kui p\u00e4ring tagastab ainult \u00fche rea, siis p\u00e4ringute paralleelne t\u00f6\u00f6tlemine ainult aeglustab seda.<\/li>\n<li>Arendajad armastavad kasutada TPC-H tulemusi. V\u00f5ib-olla on teil sarnaseid p\u00e4ringuid ideaalse paralleelse t\u00e4itmise jaoks.<\/li>\n<li>Ainult SELECT p\u00e4ringud, millel ei ole predikaadi lukustust, saavad t\u00f6\u00f6tada paralleelselt.<\/li>\n<li>M\u00f5nikord on \u00f5ige indekseerimine parem kui tabeli j\u00e4rjestikune skaneerimine paralleelses re\u017eiimis.<\/li>\n<li>P\u00e4ringute peatamine ja kursused ei ole toetatud.<\/li>\n<li>Aknafunktsioonid ja j\u00e4rjestatud komplektide agregaadifunktsioonid ei ole paralleelsed.<\/li>\n<li>Te ei saavutada sisend-v\u00e4ljund koormuses midagi.<\/li>\n<li>Paralleelseid j\u00e4rjestusalgoritme ei eksisteeri. Kuid sortimiseta p\u00e4ringud saavad m\u00f5nedes aspektides t\u00f6\u00f6tada paralleelselt.<\/li>\n<li>Asendage CTE (WITH \u2026) sisemise SELECT-iga, et lubada paralleelset t\u00f6\u00f6tlemist.<\/li>\n<li>Kolmandate osapoolte andmete m\u00e4hised ei toeta veel paralleelset t\u00f6\u00f6tlemist (kuigi v\u00f5iks!).<\/li>\n<li>FULL OUTER JOIN ei ole toetatud.<\/li>\n<li>max_rows v\u00e4listab paralleelse t\u00f6\u00f6tlemise.<\/li>\n<li>Kui p\u00e4ringus on funktsioon, mida ei ole m\u00e4rgitud kui PARALLEL SAFE, on see \u00fche protsessoriga.<\/li>\n<li>Tehingute isolatsiooni tase SERIALIZABLE v\u00e4listab paralleelse t\u00f6\u00f6tlemise.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"testovaya-sreda\">Testimisalune<\/h3>\n<p><\/p>\n<p>PostgreSQL arendajad p\u00fc\u00fcdsid v\u00e4hendada TPC-H m\u00f5\u00f5tmise p\u00e4ringute reageerimise aega. Laadige alla m\u00f5\u00f5tmine ja <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/tvondra\/pg_tpch\">kohandage see PostgreSQL-iga<\/a><\/noindex>. See TPC-H m\u00f5\u00f5tmise mitteametlik kasutamine ei ole m\u00f5eldud andmebaaside v\u00f5i varustuse v\u00f5rdlemiseks.<\/p>\n<p><\/p>\n<ol>\n<li>Lae 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>Nimeta makefile.suite \u00fcmber Makefile'iks ja muuda nagu siin on kirjeldatud: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/tvondra\/pg_tpch\">https:\/\/github.com\/tvondra\/pg_tpch <\/a><\/noindex>. Koodi kompileerimiseks kasuta k\u00e4sku make.<\/li>\n<li>Genereeri andmed: <code>.\\\/dbgen -s 10<\/code> loomiseks suurus 23 GB. Seda on piisavalt, et n\u00e4ha erinevusi paralleelsete ja mitteparalleelsete p\u00e4ringute tulemustes.<\/li>\n<li>Muuda failid <code>tbl<\/code> ja <code>csv for<\/code> ja <code>sed<\/code>.<\/li>\n<li>Kloonige hoidla <code>pg_tpch<\/code> ja kopeerige failid <code>csv<\/code> ja <code>pg_tpch\\\/dss\\\/data<\/code>.<\/li>\n<li>Looge p\u00e4ringud k\u00e4suga <code>qgen<\/code>.<\/li>\n<li>Laadige andmed andmebaasi 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 kuna andmed on jaotatud paljude protsessorituumade vahel. Kaasaegsetes ops\u00fcsteemides PostgreSQL andmefailid vahem\u00e4lustuvad h\u00e4sti. Eelneva lugemise abil saab salvestusmuutjalt lugeda rohkem plokke, kui PG teenus n\u00f5uab. Seet\u00f5ttu ei piira p\u00e4ringu j\u00f5udlus ketta sisend-v\u00e4ljundit. See kulutab protsessori ts\u00fckleid, et:<\/p>\n<p><\/p>\n<ul>\n<li>lugeda ridu \u00fckshaaval tabeli lehtedelt;<\/li>\n<li>v\u00f5rrelda ridade v\u00e4\u00e4rtusi ja tingimusi <code>KUS<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<p>Teeme lihtsa p\u00e4ringu <code>select<\/code>:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">tpch=# selgita anal\u00fc\u00fcsi p\u00e4ringut select l_quantity as sum_qty from lineitem where l_shipdate &lt;= date &#039;1998-12-01&#039; - interval &#039;105&#039; day;\nK\u00dcSIMUSE PLaan\n--------------------------------------------------------------------------------------------------------------------------\nJ\u00e4rjekordne skaneerimine lineitem (kulu=0.00..1964772.00 read=58856235 laius=5) (aktiivne aeg=0.014..16951.669 read=58839715 ts\u00fcklid=1)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::timestamp ilma ajav\u00f6\u00f6ndita)\nFiltri j\u00e4rgi eemaldatud read: 1146337\nPlaneerimise aeg: 0.203 ms\nTeostamise aeg: 19035.100 ms<\/code><\/pre>\n<p><\/p>\n<p>J\u00e4rjekordne skaneerimine annab liigselt ridu ilma agregatsioonita, nii et p\u00e4ring tehakse \u00fche protsessorituuma poolt.<\/p>\n<p><\/p>\n<p>Kui lisada <code>SUM()<\/code>, on n\u00e4ha, et kaks t\u00f6\u00f6h\u00f5ivet aitavad p\u00e4ringu kiirusel:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">selgita anal\u00fc\u00fcsi p\u00e4ringut select sum(l_quantity) as sum_qty from lineitem where l_shipdate &lt;= date &#039;1998-12-01&#039; - interval &#039;105&#039; day;\nK\u00dcSIMUSE PLaan\n----------------------------------------------------------------------------------------------------------------------------------------------------\nL\u00f5peta agregaat (kulu=1589702.14..1589702.15 read=1 laius=32) (aktiivne aeg=8553.365..8553.365 read=1 ts\u00fcklid=1)\n-&gt; Koguge (kulu=1589701.91..1589702.12 read=2 laius=32) (aktiivne aeg=8553.241..8555.067 read=3 ts\u00fcklid=1)\nPlaanitavad t\u00f6\u00f6tajad: 2\nK\u00e4ivitatud t\u00f6\u00f6tajad: 2\n-&gt; Osaline agregaat (kulu=1588701.91..1588701.92 read=1 laius=32) (aktiivne aeg=8547.546..8547.546 read=1 ts\u00fcklid=3)\n-&gt; Paralleelne j\u00e4rjekordne skaneerimine lineitem (kulu=0.00..1527393.33 read=24523431 laius=5) (aktiivne aeg=0.038..5998.417 read=19613238 ts\u00fcklid=3)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::timestamp ilma ajav\u00f6\u00f6ndita)\nFiltri j\u00e4rgi eemaldatud read: 382112\nPlaneerimise aeg: 0.241 ms\nTeostamise 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; genereerib osaliselt agregatsiooni jaoks ridu. Nood &#171;Partial Aggregate&#187; k\u00e4rbib neid ridu koos <code>SUM()<\/code>. L\u00f5pus kogub iga t\u00f6\u00f6protsessi SUMi loendur nood &#171;Gather&#187;.<\/p>\n<p><\/p>\n<p>L\u00f5plik tulemus arvutatakse noodiga &#171;Finalize Aggregate&#187;. Kui teil on oma agregatsioonifunktsioonid, siis \u00e4rge unustage neid m\u00e4rkida 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 serveri taask\u00e4ivitamiseta:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">selgita anal\u00fc\u00fcsi p\u00e4ringut select sum(l_quantity) as sum_qty from lineitem where l_shipdate &lt;= date &#039;1998-12-01&#039; - interval &#039;105&#039; day;\nK\u00dcSIMUSE PLaan\n----------------------------------------------------------------------------------------------------------------------------------------------------\nL\u00f5peta agregaat (kulu=1589702.14..1589702.15 read=1 laius=32) (aktiivne aeg=8553.365..8553.365 read=1 ts\u00fcklid=1)\n-&gt; Koguge (kulu=1589701.91..1589702.12 read=2 laius=32) (aktiivne aeg=8553.241..8555.067 read=3 ts\u00fcklid=1)\nPlaanitavad t\u00f6\u00f6tajad: 2\nK\u00e4ivitatud t\u00f6\u00f6tajad: 2\n-&gt; Osaline agregaat (kulu=1588701.91..1588701.92 read=1 laius=32) (aktiivne aeg=8547.546..8547.546 read=1 ts\u00fcklid=3)\n-&gt; Paralleelne j\u00e4rjekordne skaneerimine lineitem (kulu=0.00..1527393.33 read=24523431 laius=5) (aktiivne aeg=0.038..5998.417 read=19613238 ts\u00fcklid=3)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::timestamp ilma ajav\u00f6\u00f6ndita)\nFiltri j\u00e4rgi eemaldatud read: 382112\nPlaneerimise aeg: 0.241 ms\nTeostamise aeg: 8555.131 ms<\/code><\/pre>\n<p><\/p>\n<p>Mis siin juhtub? T\u00f6\u00f6protsesside arv on kahekordistunud, kuid p\u00e4ring on muutunud vaid 1,6599 korda kiiremaks. Arvutused on huvitavad. Meil oli 2 t\u00f6\u00f6protsessi ja 1 juht. P\u00e4rast muutmist on see 4+1.<\/p>\n<p><\/p>\n<p>Meie maksimaalne kiirus, mis tuleneb paralleelsest t\u00f6\u00f6tlemisest: 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 juhtimisprotsessist. Juht tegeleb k\u00f5igi mitte-paralleelsete ja osa paralleelse t\u00f6\u00f6tlemisega. Teisi protsesse, 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> (alates versioonist 9.4). Kuna PostgreSQL muud osad kasutavad protsesse, mitte l\u00f5ime, v\u00f5is p\u00e4ring 3 t\u00f6\u00f6protsessiga olla 4 korda kiirem traditsioonilisest t\u00f6\u00f6tlemisest.<\/p>\n<p><\/p>\n<h3 id=\"vzaimodeystvie\">Koost\u00f6\u00f6<\/h3>\n<p><\/p>\n<p>T\u00f6\u00f6protsessid suhtlevad juhiga s\u00f5numij\u00e4rjekorra kaudu (\u00fcldise m\u00e4lu p\u00f5hjal). Igal protsessil on 2 j\u00e4rjekorda: veaparanduse ja tuplede jaoks.<\/p>\n<p><\/p>\n<h3 id=\"skolko-nuzhno-rabochih-processov\">Kui palju t\u00f6\u00f6protsesse on vaja?<\/h3>\n<p><\/p>\n<p>Minimaalne piirang m\u00e4\u00e4rab parameeter <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>. Siis p\u00e4ringute t\u00e4itja v\u00f5tab t\u00f6\u00f6protsessid basseinist, mida 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>, st taustprotsesside koguarv.<\/p>\n<p><\/p>\n<p>Kui t\u00f6\u00f6protsessi eraldamine eba\u00f5nnestub, on t\u00f6\u00f6tlemine \u00fches protsessis.<\/p>\n<p><\/p>\n<p>P\u00e4ringute planeerija v\u00f5ib v\u00e4hendada t\u00f6\u00f6protsesside arvu tabeli v\u00f5i indeksi suuruse p\u00f5hjal. Selleks 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>Igal korral, kui tabel on 3 korda suurem kui <code>min_parallel_(index|table)_scan_size<\/code>, lisab Postgres t\u00f6\u00f6protsessi. T\u00f6\u00f6protsesside arv ei p\u00f5hine kuludel. Ringikujuline s\u00f5ltuvus raskendab keeruliste rakenduste loomist. Selle asemel kasutab planeerija lihtsaid reegleid.<\/p>\n<p><\/p>\n<p>Praktikas ei ole need reeglid alati tootmisoludes sobivad, seega on v\u00f5imalik muuta t\u00f6\u00f6protsesside 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>Lisaks pika nimekirja piirangutele on veel 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 l\u00fchikeste p\u00e4ringute paralleelset t\u00f6\u00f6tlemist. 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>: juhendaja vahetus teiste t\u00f6\u00f6tajatega v\u00f5ib pikendada proportsionaalselt t\u00f6\u00f6tlemiste arvu t\u00f5ttu. See parameeter arvestab andmevahetuse kulusid.<\/p>\n<p><\/p>\n<h3 id=\"soedineniya-vlozhennyh-ciklov--nested-loop-join\">Sisemised ts\u00fcklite \u00fchendused \u2014 Nested Loop Join<\/h3>\n<p><\/p>\n<pre><code class=\"plaintext\">PostgreSQL 9.6+ saab sisemist silmust paralleelselt t\u00e4ita \u2014 see on lihtne operatsioon.\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 '%specialposits%'\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 !~~ '%specialposits%'::text)<\/code><\/pre>\n<p><\/p>\n<p>Kogumine toimub viimases etapis, seega on Nested Loop Left Join paralleelne operatsioon. Parallel Index Only Scan ilmus alles versioonis 10. See t\u00f6\u00f6tab sarnaselt paralleelsele j\u00e4rjestikusele skaneerimisele. Tingimus <code>c_custkey = o_custkey<\/code> loeb iga kliendi rea jaoks \u00fche tellimuse. Seega see ei ole paralleelne.<\/p>\n<p><\/p>\n<h3 id=\"hesh-soedinenie--hash-join\">Rohesidel \u00fchendamine \u2014 Hash Join<\/h3>\n<p><\/p>\n<p>Iga t\u00f6\u00f6tlemisprotsess loob oma h\u00e4shtiabeli kuni PostgreSQL 11. Ja kui neid protsesse on rohkem kui neli, ei parane j\u00f5udlus. Uues versioonis on h\u00e4stitaabel \u00fchine. Iga t\u00f6\u00f6tlemisprotsess v\u00f5ib kasutada WORK_MEM, et luua h\u00e4shtiabel.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">valige\n        l_shipmode,\n        sum(case\n                kui o_orderpriority = '1-URGENT'\n                        v\u00f5i o_orderpriority = '2-HIGH'\n                        siis 1\n                muu juhul 0\n        end) kui high_line_count,\n        sum(case\n                kui o_orderpriority  '1-URGENT'\n                        ja o_orderpriority  '2-HIGH'\n                        siis 1\n                muu juhul 0\n        end) kui low_line_count\nalates\n        orders,\n        lineitem\nkui\n        o_orderkey = l_orderkey\n        ja l_shipmode in ('MAIL', 'AIR')\n        ja l_commitdate &lt; l_receiptdate\n        ja l_shipdate = kuup\u00e4ev '1996-01-01'\n        ja l_receiptdate &lt; kuup\u00e4ev &#039;1996-01-01&#039; + intervall &#039;1&#039; aasta\nr\u00fchmitama\n        l_shipmode\nj\u00e4rjestama\n        l_shipmode\nPIIRDED 1;\n                                                                                                                                    K\u00dcSIMUSE PLANEERIMINE\n-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n Piirang (kulud=1964755.66..1964961.44 read=1 laius=27) (tegelik aeg=7579.592..7922.997 read=1 ts\u00fcklis=1)\n   -&gt;  Finalize GroupAggregate  (kulud=1964755.66..1966196.11 read=7 laius=27) (tegelik aeg=7579.590..7579.591 read=1 ts\u00fcklis=1)\n         R\u00fchma v\u00f5ti: lineitem.l_shipmode\n         -&gt;  Gather Merge  (kulud=1964755.66..1966195.83 read=28 laius=27) (tegelik aeg=7559.593..7922.319 read=6 ts\u00fcklis=1)\n               Planeeritud t\u00f6\u00f6tajad: 4\n               Alustatud t\u00f6\u00f6tajad: 4\n               -&gt;  Partial GroupAggregate  (kulud=1963755.61..1965192.44 read=7 laius=27) (tegelik aeg=7548.103..7564.592 read=2 ts\u00fcklis=5)\n                     R\u00fchma v\u00f5ti: lineitem.l_shipmode\n                     -&gt;  Sort  (kulud=1963755.61..1963935.20 read=71838 laius=27) (tegelik aeg=7530.280..7539.688 read=62519 ts\u00fcklis=5)\n                           Sortimisv\u00f5ti: lineitem.l_shipmode\n                           Sortimise meetod: v\u00e4lispidine liitmine Disk: 2304kB\n                           T\u00f6\u00f6line 0:  Sortimise meetod: v\u00e4lispidine liitmine Disk: 2064kB\n                           T\u00f6\u00f6line 1:  Sortimise meetod: v\u00e4lispidine liitmine Disk: 2384kB\n                           T\u00f6\u00f6line 2:  Sortimise meetod: v\u00e4lispidine liitmine Disk: 2264kB\n                           T\u00f6\u00f6line 3:  Sortimise meetod: v\u00e4lispidine liitmine Disk: 2336kB\n                           -&gt;  Parallel Hash Join  (kulud=382571.01..1957960.99 read=71838 laius=27) (tegelik aeg=7036.917..7499.692 read=62519 ts\u00fcklis=5)\n                                 Hash Tingimus: (lineitem.l_orderkey = orders.o_orderkey)\n                                 -&gt;  Parallel Seq Scan on lineitem  (kulud=0.00..1552386.40 read=71838 laius=19) (tegelik aeg=0.583..4901.063 read=62519 ts\u00fcklis=5)\n                                       Filter: ((l_shipmode = ANY (&#039;{MAIL,AIR}&#039;::bpchar[])) JA (l_commitdate &lt; l_receiptdate) JA (l_shipdate = '1996-01-01'::kuup\u00e4ev) JA (l_receiptdate &lt; &#039;1997-01-01 00:00:00&#039;::aeg ilma ajav\u00f6\u00f6ndita))\n                                       Ridu eemaldatud filtrist: 11934691\n                                 -&gt;  Parallel Hash  (kulud=313722.45..313722.45 read=3750045 laius=20) (tegelik aeg=2011.518..2011.518 read=3000000 ts\u00fcklis=5)\n                                       Baki: 65536  Partiid: 256  M\u00e4lu kasutus: 3840kB\n                                       -&gt;  Parallel Seq Scan on orders  (kulud=0.00..313722.45 read=3750045 laius=20) (tegelik aeg=0.029..995.948 read=3000000 ts\u00fcklis=5)\n Planeerimise aeg: 0.977 ms\n T\u00e4itmise aeg: 7923.770 ms<\/code><\/pre>\n<p><\/p>\n<p>K\u00fcsimus 12 TPC-H n\u00e4itab selgelt parallelset r\u00e4siv\u00f5rku. Iga t\u00f6\u00f6protsess osaleb \u00fchise r\u00e4sitabeli loomisel.<\/p>\n<p><\/p>\n<h3 id=\"soedinenie-sliyaniem--merge-join\">\u00dchendamine koondamisega \u2014 Merge Join<\/h3>\n<p><\/p>\n<p>\u00dchendamine koondamisega on olemuselt mitteparalleelne. \u00c4ra muretse, kui see on p\u00e4ringu viimane etapp, \u2014 see v\u00f5ib ikkagi toimuda paralleelselt.<\/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\t\tp_partkey = ps_partkey\n\t\tja s_suppkey = ps_suppkey\n\t\tja p_size = 36\n\t\tja p_type nagu &#039;%BRASS&#039;\n\t\tja s_nationkey = n_nationkey\n\t\tja n_regionkey = r_regionkey\n\t\tja r_name = &#039;AMERICA&#039;\n\t\tja ps_supplycost = (\n\t\t\tvali\n\t\t\tmin(ps_supplycost)\n\t\t\tpartsupp, supplier, nation, region\n\t\t\tkus\n\t\t\tp_partkey = ps_partkey\n\t\t\tja s_suppkey = ps_suppkey\n\t\t\tja s_nationkey = n_nationkey\n\t\t\tja n_regionkey = r_regionkey\n\t\t\tja r_name = &#039;AMERICA&#039;\n\t\t)\nj&auml;rjestus s_acctbal desc, n_name, s_name, p_partkey\nPIIRANG 100;\n\t\t\tK&Uuml;SIMUSE PLANEERIMINE\n----------------------------------------------------------------------------------------------------------\n Piirang\n   -&amp;gt;  Sort\n         Sort Key: supplier.s_acctbal DESC, nation.n_name, supplier.s_name, part.p_partkey\n         -&amp;gt;  Merge Join\n               Merge Cond: (part.p_partkey = partsupp.ps_partkey)\n               Join Filter: (partsupp.ps_supplycost = (Alluvusplaan 1))\n               -&amp;gt;  Koguge Merged\n                     Plaanitud T&ouml;&ouml;tajad: 4\n                     -&amp;gt;  Paralleelne Indeksi Skaneerimine kasutades &lt;strong&gt;part_pkey&lt;\/strong&gt; os part\n                           Filter: (((p_type)::text ~~ &#039;%BRASS&#039;::text) JA (p_size = 36))\n               -&amp;gt;  Materjaliseerimise\n                     -&amp;gt;  Sorteerimine\n                           Sort Key: partsupp.ps_partkey\n                           -&amp;gt;  Sisej&otilde;ud\n                                 -&amp;gt;  Sisej&otilde;ud\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;  Indeksi Skaneerimine kasutades idx_partsupp_suppkey on partsupp\n                                       Index Cond: (ps_suppkey = supplier.s_suppkey)\n               Alluvusplaan 1\n                 -&amp;gt;  Agregaat\n                       -&amp;gt;  Sisej&otilde;ud\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;  Sisej&otilde;ud\n                                   -&amp;gt;  Sisej&otilde;ud\n                                         -&amp;gt;  Indeksi Skaneerimine kasutades idx_partsupp_partkey on partsupp partsupp_1\n                                               Index Cond: (part.p_partkey = ps_partkey)\n                                         -&amp;gt;  Indeksi Skaneerimine kasutades supplier_pkey on supplier supplier_1\n                                               Index Cond: (s_suppkey = partsupp_1.ps_suppkey)\n                                   -&amp;gt;  Indeksi Skaneerimine kasutades 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. Nii et koosseis ei kasuta paralleelset t\u00f6\u00f6tlemist. Kuid nood &#171;Parallel Index Scan&#187; aitab ikkagi segmendi puhul. <code>part_pkey<\/code>.<\/p>\n<p><\/p>\n<h3 id=\"soedinenie-po-sekciyam\">Jaotiste 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\">jaotiste kaupa \u00fchendamine<\/a><\/noindex> on vaikimisi keelatud: sellel on v\u00e4ga kulukas planeerimine. Sarnaste jaotistega tabeleid saab \u00fchendama jaotiste kaupa. Nii kasutab Postgres v\u00e4iksemaid r\u00e4sitabelid. Iga jaotise \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 &lt;= 10000))\n         -&gt;  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 &lt;= 10000))\n         -&gt;  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 &lt;= 10000))\n               -&gt;  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 &lt;= 10000))\n               -&gt;  Parallel Hash\n                     -&gt;  Parallel Seq Scan on prt1_p1 t1\n                           Filter: (b = 0)<\/code><\/pre>\n<p><\/p>\n<p>Peamine on see, et jaotiste kaupa \u00fchendamine toimub paralleelselt vaid siis, kui need jaotised 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 erinevate plokkide jaoks erinevates t\u00f6\u00f6protsessides. Seda esineb tavaliselt UNION ALL p\u00e4ringutes. Puuduseks on v\u00e4iksem paralleelsus, kuna iga t\u00f6\u00f6protsess t\u00f6\u00f6tleb vaid 1 p\u00e4ringut.<\/p>\n<p><\/p>\n<p>K\u00e4imas on 2 t\u00f6\u00f6protsessi, kuigi sisse on l\u00fclitatud 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   Parallel Append\n         -&gt;  Aggregate\n               -&gt;  Seq Scan on lineitem\n                     Filter: (l_shipdate   Aggregate\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 piirab m\u00e4lu kogust iga protsessi jaoks, mitte ainult p\u00e4ringute jaoks: work_mem <em> protsessid <\/em> \u00fchendused = v\u00e4ga suur m\u00e4lukasutus.<\/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 kasutatav programm kasutab paralleelse t\u00f6\u00f6tlemise jaoks plaanis.<\/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\u00f6tavate protsesside koguarvu serveri CPU s\u00fcdamike arvu p\u00f5hjal.<\/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\">Summary<\/h3>\n<p><\/p>\n<p>Alates versioonist 9.6 v\u00f5ivad paralleelne t\u00f6\u00f6tlemine oluliselt parandada keeruliste p\u00e4ringute j\u00f5udlust, mis skaneerivad palju ridu v\u00f5i indekseid. PostgreSQL 10-s on paralleelne t\u00f6\u00f6tlemine vaikimisi sisse l\u00fclitatud. \u00c4rge unustage seda v\u00e4lja l\u00fclitada serverites, kus on suur OLTP koormus. J\u00e4rjekorraskannid v\u00f5i indeksiskannid kasutavad v\u00e4ga palju ressursse. Kui te ei tee aruannet kogu andmestiku p\u00f5hjal, v\u00f5ib p\u00e4ringute tootlikkust suurendada, lihtsalt lisades vajalikke indekseid v\u00f5i kasutades \u00f5iget osade jagamist.<\/p>\n<p><\/p>\n<h3 id=\"ssylki\">Viidatud 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-s<\/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.1.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.\" \/>\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.1.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.\" \/>\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-s | ProHoster","description":"Kaasaegsetes CPU-des on palju s\u00fcdamikke.","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.","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}]}}