{"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\/hu\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql","title":{"rendered":"P\u00e1rhuzamos lek\u00e9rdez\u00e9sek PostgreSQL-ben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"P\u00e1rhuzamos lek\u00e9rdez\u00e9sek PostgreSQL-ben\" src=\"\/wp-content\/uploads\/2019\/04\/bbb4b4d3f8714bbdb9b26ada2f2253b5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nA modern CPU has many cores. For years, applications have been sending requests to databases in parallel. If it's a reporting request for many rows in a table, it executes faster when multiple CPUs are involved, and in PostgreSQL, this has been possible since version 9.6.<\/p>\n<p><\/p>\n<p>It took 3 years to implement the parallel query feature \u2014 the code had to be rewritten at various stages of query execution. PostgreSQL 9.6 introduced the infrastructure for further code enhancements. In later versions, other types of queries can also be executed in parallel.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"ogranicheniya\">Korl\u00e1toz\u00e1sok<\/h3>\n<p><\/p>\n<ul>\n<li>Do not enable parallel execution if all cores are already busy, otherwise, other queries will slow down.<\/li>\n<li>Most importantly, parallel processing with high WORK_MEM values consumes a lot of memory \u2014 each hash connection or sorting operation takes up memory equivalent to work_mem.<\/li>\n<li>OLTP queries with low latency cannot be accelerated through parallel execution. If a query returns a single row, parallel processing will only slow it down.<\/li>\n<li>Developers love using the TPC-H benchmark. Maybe you have similar queries for optimal parallel execution.<\/li>\n<li>Only SELECT queries without predicate locking execute in parallel.<\/li>\n<li>Sometimes proper indexing is better than sequential table scanning in parallel mode.<\/li>\n<li>Query suspensions and cursors are not supported.<\/li>\n<li>Window functions and aggregate functions of ordered sets are not parallel.<\/li>\n<li>You gain nothing in I\/O workload.<\/li>\n<li>There are no parallel sorting algorithms. However, queries with sorts can execute in parallel in some aspects.<\/li>\n<li>Replace CTE (WITH \u2026) with a nested SELECT to enable parallel processing.<\/li>\n<li>Third-party data wrappers do not currently support parallel processing (but they could!).<\/li>\n<li>FULL OUTER JOIN is not supported.<\/li>\n<li>max_rows disables parallel processing.<\/li>\n<li>If a function in the query is not marked as PARALLEL SAFE, it will be single-threaded.<\/li>\n<li>The SERIALIZABLE transaction isolation level disables parallel processing.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"testovaya-sreda\">Tesztk\u00f6rnyezet<\/h3>\n<p><\/p>\n<p>PostgreSQL developers tried to reduce the response time of TPC-H benchmark queries. Download the benchmark and <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/tvondra\/pg_tpch\">adapt it to PostgreSQL<\/a><\/noindex>. This unofficial use of the TPC-H benchmark is not for comparing databases or hardware.<\/p>\n<p><\/p>\n<ol>\n<li>T\u00f6ltse le a TPC-H_Tools_v2.17.3.zip f\u00e1jlt (vagy egy \u00fajabb verzi\u00f3t) <noindex><a rel=\"nofollow\" href=\"http:\/\/www.tpc.org\/tpc_documents_current_versions\/current_specifications.asp\">a TPC hivatalos oldal\u00e1r\u00f3l<\/a><\/noindex>.<\/li>\n<li>Renommozza a makefile.suite f\u00e1jlt Makefile n\u00e9vre, \u00e9s m\u00f3dos\u00edtsa az al\u00e1bbiak szerint: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/tvondra\/pg_tpch\">https:\/\/github.com\/tvondra\/pg_tpch <\/a><\/noindex>. A k\u00f3dot a make parancs v\u00e9grehajt\u00e1s\u00e1val ford\u00edtsa le.<\/li>\n<li>Gener\u00e1ljon adatokat: <code>.\/dbgen -s 10<\/code> ez egy 23 GB-os adatb\u00e1zist hoz l\u00e9tre. Ez elegend\u0151 ahhoz, hogy l\u00e1ssa a p\u00e1rhuzamos \u00e9s nem p\u00e1rhuzamos lek\u00e9rdez\u00e9sek teljes\u00edtm\u00e9nyk\u00fcl\u00f6nbs\u00e9g\u00e9t.<\/li>\n<li>Konvert\u00e1lja a f\u00e1jlokat <code>tbl<\/code> be. <code>csv form\u00e1tumba a for<\/code> \u00e9s <code>sed<\/code>.<\/li>\n<li>Kl\u00f3nozza a t\u00e1rol\u00f3t <code>pg_tpch<\/code> \u00e9s m\u00e1solja a f\u00e1jlokat <code>csv<\/code> be. <code>pg_tpch\/dss\/data<\/code>.<\/li>\n<li>Hozza l\u00e9tre a lek\u00e9rdez\u00e9seket a parancs seg\u00edts\u00e9g\u00e9vel <code>qgen<\/code>.<\/li>\n<li>T\u00f6ltse fel az adatokat a k\u00f6vetkez\u0151 paranccsal: <code>.\/tpch.sh<\/code>.<\/li>\n<\/ol>\n<p><\/p>\n<h3 id=\"parallelnoe-posledovatelnoe-skanirovanie\">P\u00e1rhuzamos soros beolvas\u00e1s<\/h3>\n<p><\/p>\n<p>Ez nem felt\u00e9tlen\u00fcl a p\u00e1rhuzamos olvas\u00e1s miatt lehet gyorsabb, hanem mert az adatok sok processzormag k\u00f6z\u00f6tt oszlanak el. A modern oper\u00e1ci\u00f3s rendszerek j\u00f3l gyors\u00edtj\u00e1k a PostgreSQL adatf\u00e1jlokat. El\u0151rel\u00e1t\u00f3 olvas\u00e1ssal egy blokkot is kaphatunk a t\u00e1rol\u00f3b\u00f3l, ami nagyobb lehet, mint amit a PG d\u00e9mon k\u00e9r. \u00cdgy a lek\u00e9rdez\u00e9s teljes\u00edtm\u00e9nye nem korl\u00e1toz\u00f3dik a lemez I\/O-ra. CPU ciklusokat haszn\u00e1l, hogy:<\/p>\n<p><\/p>\n<ul>\n<li>egyes\u00e9vel olvassa a sorokat a t\u00e1bl\u00e1zat lapjain;<\/li>\n<li>\u00f6sszehasonl\u00edtsa a sorok \u00e9rt\u00e9keit \u00e9s a felt\u00e9teleket <code>AHOL<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<p>Futtassunk egy egyszer\u0171 lek\u00e9rdez\u00e9st <code>select<\/code>:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">tpch=# explain analyze select l_quantity as sum_qty from lineitem where l_shipdate &lt;= date &#039;1998-12-01&#039; - interval &#039;105&#039; day;\nQUERY PLAN\n--------------------------------------------------------------------------------------------------------------------------\nSeq Scan on lineitem (cost=0.00..1964772.00 rows=58856235 width=5) (actual time=0.014..16951.669 rows=58839715 loops=1)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::timestamp without time zone)\nRows Removed by Filter: 1146337\nPlanning Time: 0.203 ms\nExecution Time: 19035.100 ms<\/code><\/pre>\n<p><\/p>\n<p>A soros beolvas\u00e1s t\u00fal sok sort ad vissza aggreg\u00e1l\u00e1s n\u00e9lk\u00fcl, ez\u00e9rt a lek\u00e9rdez\u00e9st egyetlen CPU mag hajtja v\u00e9gre.<\/p>\n<p><\/p>\n<p>Ha hozz\u00e1adunk egyet <code>SUM()<\/code>, l\u00e1that\u00f3an k\u00e9t munkafolyamat seg\u00edt a lek\u00e9rdez\u00e9s gyorsabb\u00e1 t\u00e9tel\u00e9ben:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate  Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)\nWorkers Planned: 2\nWorkers Launched: 2\n-&gt; Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)\n-&gt; P\u00e1rhuzamos Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::timestamp without time zone)\nRows Removed by Filter: 382112\nPlanning Time: 0.241 ms\nExecution Time: 8555.131 ms<\/code><\/pre>\n<p><\/p>\n<h3 id=\"parallelnaya-agregaciya\">P\u00e1rhuzamos aggreg\u00e1ci\u00f3<\/h3>\n<p><\/p>\n<p>A 'Parallel Seq Scan' node produces rows for partial aggregation. The 'Partial Aggregate' node trims these rows using <code>SUM()<\/code>. At the end, the SUM counter from each worker process is collected by the 'Gather' node.<\/p>\n<p><\/p>\n<p>The final result is calculated by the 'Finalize Aggregate' node. If you have your own aggregation functions, be sure to mark them as 'parallel safe'.<\/p>\n<p><\/p>\n<h3 id=\"kolichestvo-rabochih-processov\">A munkafolyamatok sz\u00e1ma<\/h3>\n<p><\/p>\n<p>A munkafolyamatok sz\u00e1ma \u00fajraind\u00edt\u00e1s n\u00e9lk\u00fcl n\u00f6velhet\u0151 a szerveren:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate  Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)\nWorkers Planned: 2\nWorkers Launched: 2\n-&gt; Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)\n-&gt; P\u00e1rhuzamos Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)\nFilter: (l_shipdate &lt;= &#039;1998-08-18 00:00:00&#039;::timestamp without time zone)\nRows Removed by Filter: 382112\nPlanning Time: 0.241 ms\nExecution Time: 8555.131 ms<\/code><\/pre>\n<p><\/p>\n<p>Mi t\u00f6rt\u00e9nik itt? A munkafolyamatok sz\u00e1ma megdupl\u00e1z\u00f3dott, mik\u00f6zben a k\u00e9r\u00e9s csup\u00e1n 1,6599-szer gyorsabb lett. \u00c9rdekes sz\u00e1m\u00edt\u00e1sok. Eleinte 2 munkafolyamatunk volt \u00e9s 1 vezet\u0151. A v\u00e1ltoztat\u00e1s ut\u00e1n 4+1 lett.<\/p>\n<p><\/p>\n<p>A p\u00e1rhuzamos feldolgoz\u00e1sunk maxim\u00e1lis gyorsul\u00e1sa: 5\/3 = 1,66(6) szoros.<\/p>\n<p><\/p>\n<h2 id=\"kak-eto-rabotaet\">Hogyan m\u0171k\u00f6dik ez?<\/h2>\n<p><\/p>\n<h3 id=\"processy\">Folyamatok<\/h3>\n<p><\/p>\n<p>A k\u00e9r\u00e9s v\u00e9grehajt\u00e1sa mindig a vezet\u0151 folyamatb\u00f3l indul. A vezet\u0151 kezeli a teljes nem p\u00e1rhuzamos \u00e9s a r\u00e9szben p\u00e1rhuzamos feldolgoz\u00e1st. A t\u00f6bbi folyamat, amely ugyanazokat a k\u00e9r\u00e9seket dolgozza fel, munkafolyamatoknak nevezz\u00fck. A p\u00e1rhuzamos feldolgoz\u00e1s az infrastrukt\u00far\u00e1t haszn\u00e1lja <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/11\/bgworker.html\">dinamikus h\u00e1tt\u00e9r munkafolyamatok<\/a><\/noindex> (a 9.4-es verzi\u00f3t\u00f3l). Mivel a PostgreSQL m\u00e1s r\u00e9szei folyamatokat haszn\u00e1lnak, nem sz\u00e1lakat, a 3 munkafolyamattal rendelkez\u0151 k\u00e9r\u00e9s ak\u00e1r 4-szer is gyorsabb lehet a hagyom\u00e1nyos feldolgoz\u00e1shoz k\u00e9pest.<\/p>\n<p><\/p>\n<h3 id=\"vzaimodeystvie\">Interakci\u00f3<\/h3>\n<p><\/p>\n<p>A munkafolyamatok \u00fczenetsoron kereszt\u00fcl kommunik\u00e1lnak a vezet\u0151vel (megosztott mem\u00f3ria alap\u00fa). Minden folyamatnak 2 sora van: hiba\u00fczenetekre \u00e9s tuple-\u00f6kre.<\/p>\n<p><\/p>\n<h3 id=\"skolko-nuzhno-rabochih-processov\">H\u00e1ny munkafolyamatra van sz\u00fcks\u00e9g?<\/h3>\n<p><\/p>\n<p>A minim\u00e1lis korl\u00e1tot a k\u00f6vetkez\u0151 param\u00e9ter adja meg <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>. Azt\u00e1n a lek\u00e9rdez\u0151 v\u00e9grehajt\u00f3 a munkafolyamatokat a korl\u00e1tozott param\u00e9terb\u0151l veszi <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>. Az utols\u00f3 korl\u00e1t a <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>, azaz a teljes h\u00e1tt\u00e9r folyamataid sz\u00e1ma.<\/p>\n<p><\/p>\n<p>Ha nem lehet munkafolyamatot kiosztani, a feldolgoz\u00e1s egy folyamat\u00fa lesz.<\/p>\n<p><\/p>\n<p>A lek\u00e9rdez\u00e9s \u00fctemez\u0151je cs\u00f6kkentheti a munkafolyamatok sz\u00e1m\u00e1t a t\u00e1bl\u00e1zat vagy index m\u00e9rete alapj\u00e1n. Ehhez a k\u00f6vetkez\u0151 param\u00e9terek tartoznak <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> \u00e9s <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 t\u00e1bla =&gt; 1 munkafolyamat\n24MB t\u00e1bla =&gt; 2 munkafolyamat\n72MB t\u00e1bla =&gt; 3 munkafolyamat\nx =&gt; log(x \/ min_parallel_table_scan_size) \/ log(3) + 1 munkafolyamat<\/code><\/pre>\n<p><\/p>\n<p>Minden alkalommal, amikor a t\u00e1bla 3-szor nagyobb, mint <code>min_parallel_(index|table)_scan_size<\/code>, a Postgres hozz\u00e1ad egy munkafolyamatot. A munkafolyamatok sz\u00e1ma nem k\u00f6lts\u00e9gen alapul. A k\u00f6rk\u00f6r\u00f6s f\u00fcgg\u0151s\u00e9g bonyolult megval\u00f3s\u00edt\u00e1st nehez\u00edt. Ehelyett az \u00fctemez\u0151 egyszer\u0171 szab\u00e1lyokat haszn\u00e1l.<\/p>\n<p><\/p>\n<p>A gyakorlatban ezek a szab\u00e1lyok nem mindig alkalmazhat\u00f3k a termel\u00e9sre, \u00edgy a munkafolyamatok sz\u00e1m\u00e1t meg lehet v\u00e1ltoztatni egy adott t\u00e1bl\u00e1hoz: ALTER TABLE \u2026 SET (<code>parallel_workers = N<\/code>).<\/p>\n<p><\/p>\n<h3 id=\"pochemu-parallelnaya-obrabotka-ne-ispolzuetsya\">Mi\u00e9rt nem haszn\u00e1lj\u00e1k a p\u00e1rhuzamos feldolgoz\u00e1st?<\/h3>\n<p><\/p>\n<p>A hossz\u00fa korl\u00e1toz\u00e1sok list\u00e1j\u00e1n k\u00edv\u00fcl vannak k\u00f6lts\u00e9gellen\u0151rz\u00e9sek is:<\/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 hogy elker\u00fclhess\u00fck a p\u00e1rhuzamosan feldolgozott r\u00f6vid lek\u00e9rdez\u00e9seket. Ez a param\u00e9ter megbecs\u00fcli a mem\u00f3ria el\u0151k\u00e9sz\u00edt\u00e9s\u00e9nek, a folyamat elind\u00edt\u00e1s\u00e1nak \u00e9s az els\u0151 adats Exchange id\u0151t.<\/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>: a vezet\u0151 \u00e9s a munk\u00e1sok k\u00f6z\u00f6tti kommunik\u00e1ci\u00f3 ar\u00e1nyos lehet a munkafolyamatok tuple-jeinek sz\u00e1m\u00e1val. Ez a param\u00e9ter sz\u00e1molja az adatok cser\u00e9j\u00e9nek k\u00f6lts\u00e9geit.<\/p>\n<p><\/p>\n<h3 id=\"soedineniya-vlozhennyh-ciklov--nested-loop-join\">Bels\u0151 ciklusok \u00f6sszekapcsol\u00e1sa \u2014 Nested Loop Join<\/h3>\n<p><\/p>\n<pre><code class=\"plaintext\">A PostgreSQL 9.6+ p\u00e1rhuzamosan k\u00e9pes v\u00e9grehajtani a be\u00e1gyazott ciklusokat \u2014 ez egy egyszer\u0171 m\u0171velet.\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>A gy\u0171jt\u00e9s az utols\u00f3 l\u00e9p\u00e9sben t\u00f6rt\u00e9nik, \u00edgy a Nested Loop Left Join - p\u00e1rhuzamos m\u0171velet. A Parallel Index Only Scan csak a 10-es verzi\u00f3ban jelent meg. Ez hasonl\u00f3an m\u0171k\u00f6dik a p\u00e1rhuzamos szekvenci\u00e1lis vizsg\u00e1lathoz. A felt\u00e9tel <code>c_custkey = o_custkey<\/code> minden \u00fcgyf\u00e9lsorhoz egy rendel\u00e9st olvas be. \u00cdgy nem p\u00e1rhuzamos.<\/p>\n<p><\/p>\n<h3 id=\"hesh-soedinenie--hash-join\">Hash Join \u2014 Hash Join<\/h3>\n<p><\/p>\n<p>Minden munkafolyamat saj\u00e1t hash-t\u00e1bl\u00e1t k\u00e9sz\u00edt a PostgreSQL 11 el\u0151tt. \u00c9s ha ezekb\u0151l a folyamatokb\u00f3l t\u00f6bb mint n\u00e9gy van, a teljes\u00edtm\u00e9ny nem n\u00f6vekszik. Az \u00faj verzi\u00f3ban a hash-t\u00e1bla k\u00f6z\u00f6s. Minden munkafolyamat haszn\u00e1lhat WORK_MEM-t a hash-t\u00e1bla l\u00e9trehoz\u00e1s\u00e1hoz.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">select\n        l_shipmode,\n        sum(case\n                when o_orderpriority = '1-URGENT'\n                        or o_orderpriority = '2-HIGH'\n                        then 1\n                else 0\n        end) as high_line_count,\n        sum(case\n                when o_orderpriority  '1-URGENT'\n                        and o_orderpriority  '2-HIGH'\n                        then 1\n                else 0\n        end) as low_line_count\nfrom\n        orders,\n        lineitem\nwhere\n        o_orderkey = l_orderkey\n        and l_shipmode in ('MAIL', 'AIR')\n        and l_commitdate &lt; l_receiptdate\n        and l_shipdate = date '1996-01-01'\n        and l_receiptdate   Finalize GroupAggregate  (cost=1964755.66..1966196.11 rows=7 width=27) (actual time=7579.590..7579.591 rows=1 loops=1)\n         Group Key: lineitem.l_shipmode\n         -&gt;  Gather Merge  (cost=1964755.66..1966195.83 rows=28 width=27) (actual time=7559.593..7922.319 rows=6 loops=1)\n               Workers Planned: 4\n               Workers Launched: 4\n               -&gt;  Partial GroupAggregate  (cost=1963755.61..1965192.44 rows=7 width=27) (actual time=7548.103..7564.592 rows=2 loops=5)\n                     Group Key: lineitem.l_shipmode\n                     -&gt;  Sort  (cost=1963755.61..1963935.20 rows=71838 width=27) (actual time=7530.280..7539.688 rows=62519 loops=5)\n                           Sort Key: lineitem.l_shipmode\n                           Sort Method: external merge  Disk: 2304kB\n                           Worker 0:  Sort Method: external merge  Disk: 2064kB\n                           Worker 1:  Sort Method: external merge  Disk: 2384kB\n                           Worker 2:  Sort Method: external merge  Disk: 2264kB\n                           Worker 3:  Sort Method: external merge  Disk: 2336kB\n                           -&gt;  Parallel Hash Join  (cost=382571.01..1957960.99 rows=71838 width=27) (actual time=7036.917..7499.692 rows=62519 loops=5)\n                                 Hash Cond: (lineitem.l_orderkey = orders.o_orderkey)\n                                 -&gt;  Parallel Seq Scan on lineitem  (cost=0.00..1552386.40 rows=71838 width=19) (actual time=0.583..4901.063 rows=62519 loops=5)\n                                       Filter: ((l_shipmode = ANY ('{MAIL,AIR}'::bpchar[])) AND (l_commitdate &lt; l_receiptdate) AND (l_shipdate = '1996-01-01'::date) AND (l_receiptdate   Parallel Hash  (cost=313722.45..313722.45 rows=3750045 width=20) (actual time=2011.518..2011.518 rows=3000000 loops=5)\n                                       Buckets: 65536  Batches: 256  Memory Usage: 3840kB\n                                       -&gt;  Parallel Seq Scan on orders  (cost=0.00..313722.45 rows=3750045 width=20) (actual time=0.029..995.948 rows=3000000 loops=5)\n Planning Time: 0.977 ms\n Execution Time: 7923.770 ms<\/code><\/pre>\n<p><\/p>\n<p>A 12. k\u00e9rd\u00e9s a TPC-H-b\u00f3l vil\u00e1gosan bemutatja a p\u00e1rhuzamos hash-jelentkez\u00e9st. Minden munkafolyamat r\u00e9szt vesz egy k\u00f6z\u00f6s hash-t\u00e1bl\u00e1zat l\u00e9trehoz\u00e1s\u00e1ban.<\/p>\n<p><\/p>\n<h3 id=\"soedinenie-sliyaniem--merge-join\">\u00d6sszekapcsol\u00e1s egyes\u00edt\u00e9ssel \u2014 Merge Join<\/h3>\n<p><\/p>\n<p>Az \u00f6sszekapcsol\u00e1s egyes\u00edt\u00e9ssel term\u00e9szet\u00e9n\u00e9l fogva nem p\u00e1rhuzamos. Ne agg\u00f3djon, ha ez a lek\u00e9rdez\u00e9s utols\u00f3 l\u00e9p\u00e9se, \u2014 akkor is v\u00e9grehajthat\u00f3 p\u00e1rhuzamosan.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">-- Lek&eacute;rdez&eacute;s 2 a TPC-H-b&oacute;l\nexplain (costs off) select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment\nfrom    part, supplier, partsupp, nation, region\nwhere\n        p_partkey = ps_partkey\n        and s_suppkey = ps_suppkey\n        and p_size = 36\n        and p_type like &#039;%BRASS&#039;\n        and s_nationkey = n_nationkey\n        and n_regionkey = r_regionkey\n        and r_name = &#039;AMERICA&#039;\n        and ps_supplycost = (\n                select\n                        min(ps_supplycost)\n                from    partsupp, supplier, nation, region\n                where\n                        p_partkey = ps_partkey\n                        and s_suppkey = ps_suppkey\n                        and s_nationkey = n_nationkey\n                        and n_regionkey = r_regionkey\n                        and r_name = &#039;AMERICA&#039;\n        )\norder by s_acctbal desc, n_name, s_name, p_partkey\nLIMIT 100;\n                                                QUERY PLAN\n----------------------------------------------------------------------------------------------------------\n Limit\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 = (SubPlan 1))\n               -&amp;gt;  Gather Merge\n                     Workers Planned: 4\n                     -&amp;gt;  P&aacute;rhuzamos Index Ellen\u0151rz&eacute;s haszn&aacute;lat&aacute;val &lt;strong&gt;part_pkey&lt;\/strong&gt; a part\n                           Filter: (((p_type)::text ~~ &#039;%BRASS&#039;::text) AND (p_size = 36))\n               -&amp;gt;  Materializ&aacute;l&aacute;s\n                     -&amp;gt;  Sort\n                           Sort Key: partsupp.ps_partkey\n                           -&amp;gt;  Be&aacute;gyazott Ciklus\n                                 -&amp;gt;  Be&aacute;gyazott Ciklus\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;  Aggreger&eacute;s\n                       -&amp;gt;  Be&aacute;gyazott Ciklus\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;  Be&aacute;gyazott Ciklus\n                                   -&amp;gt;  Be&aacute;gyazott Ciklus\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>The 'Merge Join' node is above the 'Gather Merge'. Thus, the merge does not use parallel processing. But the 'Parallel Index Scan' node still assists with the segment. <code>part_pkey<\/code>.<\/p>\n<p><\/p>\n<h3 id=\"soedinenie-po-sekciyam\">Szekci\u00f3k szerinti \u00f6sszekapcsol\u00e1s<\/h3>\n<p><\/p>\n<p>A PostgreSQL 11-ben <noindex><a rel=\"nofollow\" href=\"http:\/\/ashutoshpg.blogspot.com\/2017\/12\/partition-wise-joins-divide-and-conquer.html\">szekci\u00f3k szerinti \u00f6sszekapcsol\u00e1s<\/a><\/noindex> alap\u00e9rtelmez\u00e9s szerint letiltva: nagyon k\u00f6lts\u00e9ges a tervez\u00e9se. Olyan t\u00e1bl\u00e1kat lehet \u00f6sszekapcsolni, amelyek hasonl\u00f3 szekci\u00f3z\u00e1ssal rendelkeznek, szekci\u00f3r\u00f3l szekci\u00f3ra. \u00cdgy a Postgres kisebb hash-t\u00e1bl\u00e1kat fog haszn\u00e1lni. Minden szekci\u00f3 \u00f6sszekapcsol\u00e1sa p\u00e1rhuzamos lehet.<\/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>A legfontosabb, hogy a szekci\u00f3k szerinti \u00f6sszekapcsol\u00e1s p\u00e1rhuzamos csak akkor, ha ezek a szekci\u00f3k elegend\u0151 nagyok.<\/p>\n<p><\/p>\n<h3 id=\"parallelnoe-dopolnenie--parallel-append\">P\u00e1rhuzamos kieg\u00e9sz\u00edt\u00e9s \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> k\u00fcl\u00f6nb\u00f6z\u0151 blokkok helyett haszn\u00e1lhat\u00f3 k\u00fcl\u00f6nb\u00f6z\u0151 munkafolyamatokban. Ezt \u00e1ltal\u00e1ban az UNION ALL lek\u00e9rdez\u00e9sekn\u00e9l tapasztalhatjuk. H\u00e1tr\u00e1ny \u2014 kevesebb p\u00e1rhuzamoss\u00e1g, mivel minden munkafolyamat csak 1 lek\u00e9rdez\u00e9st dolgoz fel.<\/p>\n<p><\/p>\n<p>Itt 2 munkafolyamat indult el, b\u00e1r 4 volt bekapcsolva.<\/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\">A legfontosabb v\u00e1ltoz\u00f3k<\/h3>\n<p><\/p>\n<ul>\n<li>A WORK_MEM korl\u00e1tozza a mem\u00f3ri\u00e1t, amely minden folyamat sz\u00e1m\u00e1ra el\u00e9rhet\u0151, nemcsak a lek\u00e9rdez\u00e9sekhez: work_mem <em> folyamatok <\/em> kapcsolatok = nagyon sok mem\u00f3ria.<\/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 h\u00e1ny munkafolyamatot haszn\u00e1l a v\u00e9grehajt\u00f3 program p\u00e1rhuzamos feldolgoz\u00e1shoz az \u00fctemez\u00e9sb\u0151l.<\/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 a munkafolyamatok \u00f6sszl\u00e9tsz\u00e1m\u00e1t a szerveren l\u00e9v\u0151 CPU magok sz\u00e1m\u00e1hoz igaz\u00edtja.<\/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 ugyanaz, de a p\u00e1rhuzamos munkafolyamatokra vonatkozik.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"itogi\">\u00d6sszegz\u00e9s<\/h3>\n<p><\/p>\n<p>A 9.6 verzi\u00f3t\u00f3l kezd\u0151d\u0151en a p\u00e1rhuzamos feldolgoz\u00e1s jelent\u0151sen jav\u00edthatja a nagy sorok vagy indexek beolvas\u00e1s\u00e1t v\u00e9gz\u0151 \u00f6sszetett lek\u00e9rdez\u00e9sek teljes\u00edtm\u00e9ny\u00e9t. A PostgreSQL 10-ben a p\u00e1rhuzamos feldolgoz\u00e1s alap\u00e9rtelmez\u00e9s szerint be van kapcsolva. Ne feledje el kikapcsolni a nagy OLTP terhel\u00e9s\u0171 szervereken. A szekvenci\u00e1lis beolvas\u00e1sok vagy indexbeolvas\u00e1sok nagyon sok er\u0151forr\u00e1st ig\u00e9nyelnek. Ha nem k\u00e9sz\u00edt jelent\u00e9st az \u00f6sszes adathalmazon, a lek\u00e9rdez\u00e9sek hat\u00e9konyabb\u00e1 tehet\u0151k, ha egyszer\u0171en hozz\u00e1adja a hi\u00e1nyz\u00f3 indexeket vagy a megfelel\u0151 part\u00edcion\u00e1l\u00e1st haszn\u00e1lja.<\/p>\n<p><\/p>\n<h3 id=\"ssylki\">Hivatkoz\u00e1sok<\/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\">P\u00e1rhuzamoss\u00e1g a PostgreSQL 11-ben<\/a><\/noindex><\/li>\n<\/ul>\n<p>Forr\u00e1s: <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.4 - 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\/hu\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hu_HU\" \/>\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\/hu\/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\udd47P\u00e1rhuzamos lek\u00e9rdez\u00e9sek a PostgreSQL-ben | ProHoster","description":"A modern CPU-kban nagyon sok mag tal\u00e1lhat\u00f3.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/parallelnye-zaprosy-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","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\/hu\/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\/hu\/wp-json\/wp\/v2\/posts\/30900","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=30900"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/30900\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/22879"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=30900"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=30900"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=30900"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}