{"id":37975,"date":"2019-10-31T22:20:56","date_gmt":"2019-10-31T19:20:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost\/"},"modified":"2019-10-31T22:20:56","modified_gmt":"2019-10-31T19:20:56","slug":"apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","title":{"rendered":"Upgrade pre leniv\u00fdch: ako PostgreSQL 12 zvy\u0161uje v\u00fdkon","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Upgrade<\/p>\n

PostgreSQL 12<\/a><\/noindex>, posledn\u00e1 verzia \u201enajlep\u0161ej na svete rela\u010dnej datab\u00e1zy s otvoren\u00fdm zdrojov\u00fdm k\u00f3dom\u201c vyjde o p\u00e1r t\u00fd\u017ed\u0148ov (ak v\u0161etko p\u00f4jde pod\u013ea pl\u00e1nu). To zodpoved\u00e1 be\u017en\u00e9mu harmonogramu \u2013 nov\u00e1 verzia s mno\u017estvom nov\u00fdch funkci\u00ed vych\u00e1dza raz ro\u010dne a, \u00faprimne povedan\u00e9, je to impozantn\u00e9. Preto som sa stal akt\u00edvnym \u010dlenom komunity PostgreSQL.<\/p>\n

<\/p>\n

Pod\u013ea m\u0148a, na rozdiel od minul\u00fdch vydan\u00ed, PostgreSQL 12 nem\u00e1 jednu alebo dve revolu\u010dn\u00e9 funkcie (ako napr\u00edklad oddelenie alebo paralelizmus dopytov). Raz som si urobil \u017eart, \u017ee hlavn\u00fdm k\u00faskom PostgreSQL 12 je v\u00e4\u010d\u0161ia stabilita. A nie je to d\u00f4le\u017eit\u00e9, ke\u010f spravujete kritick\u00e9 \u00fadaje v\u00e1\u0161ho podnikania?<\/p>\n

<\/p>\n

Ale PostgreSQL 12 t\u00fdm nekon\u010d\u00ed: s nov\u00fdmi mo\u017enos\u0165ami a vylep\u0161eniami bud\u00fa aplik\u00e1cie fungova\u0165 lep\u0161ie, a od v\u00e1s sa vy\u017eaduje len aktualiz\u00e1cia!<\/em><\/p>\n

<\/p>\n

(Mo\u017eno, e\u0161te prebudova\u0165 indexy, ale v tejto verzii to nie je tak stra\u0161n\u00e9, ako sme zvyknut\u00ed.)<\/p>\n

<\/a><\/noindex><\/p>\n

Bude \u00fa\u017easn\u00e9 \u2013 aktualizova\u0165 PostgreSQL a hne\u010f si u\u017ei\u0165 v\u00fdznamn\u00e9 zlep\u0161enia bez zbyto\u010dn\u00fdch pohybov. Pred nieko\u013ek\u00fdmi rokmi som analyzoval aktualiz\u00e1ciu z PostgreSQL 9.4 na PostgreSQL 10 a videl som, ako sa aplik\u00e1cia zr\u00fdchlila v\u010faka vylep\u0161en\u00e9mu paralelizmu dopytov v PostgreSQL 10. A, hlavne, odo m\u0148a takmer ni\u010d nebolo potrebn\u00e9 (len nastavi\u0165 konfigura\u010dn\u00fd parameter max_parallel_workers<\/code>).<\/p>\n

<\/p>\n

S\u00fahlas\u00edte, je pohodln\u00e9, ke\u010f hne\u010f po aktualiz\u00e1cii aplik\u00e1cie funguj\u00fa lep\u0161ie. A my sa ve\u013emi sna\u017e\u00edme te\u0161i\u0165 pou\u017e\u00edvate\u013eov, ve\u010f s PostgreSQL ich st\u00e1le prib\u00fada.<\/p>\n

<\/p>\n

A ako v\u00e1m jednoduch\u00e1 aktualiz\u00e1cia na PostgreSQL 12 prinesie \u0161\u0165astie? Teraz v\u00e1m to poviem.<\/p>\n

<\/p>\n

Z\u00e1va\u017en\u00e9 vylep\u0161enia indexovania<\/h3>\n

<\/p>\n

Bez indexovania sa datab\u00e1za \u010faleko nepohne. Ako inak r\u00fdchlo n\u00e1js\u0165 inform\u00e1cie? Z\u00e1kladn\u00fd syst\u00e9m indexovania PostgreSQL sa naz\u00fdva B-strom<\/a><\/noindex>. Tento typ indexu je optimalizovan\u00fd pre syst\u00e9my ukladania.<\/p>\n

<\/p>\n

Jednoducho pou\u017eijeme pr\u00edkaz CREATE INDEX ON some_table (some_column)<\/code>, a PostgreSQL vykon\u00e1 v\u00e4\u010d\u0161iu pr\u00e1cu na udr\u017eovan\u00ed aktu\u00e1lnosti indexu, zatia\u013e \u010do neust\u00e1le vklad\u00e1me, aktualizujeme a odstra\u0148ujeme hodnoty. V\u0161etko funguje samo, ako z\u00e1zrak.<\/p>\n

<\/p>\n

Ale indexy PostgreSQL maj\u00fa jeden probl\u00e9m \u2013 ony naberaj\u00fa na ve\u013ekosti.<\/a><\/noindex> a zaberaj\u00fa zbyto\u010dn\u00e9 miesto na disku, pri\u010dom sa zni\u017euje v\u00fdkon pri z\u00edskavan\u00ed a aktualizovan\u00ed \u00fadajov. Pod \u201enafukovan\u00edm\u201c mysl\u00edm neefekt\u00edvne udr\u017eiavanie indexovej \u0161trukt\u00fary. M\u00f4\u017ee to by\u0165 \u2014 a nemus\u00ed by\u0165 \u2014 spojen\u00e9 so zbyto\u010dn\u00fdmi z\u00e1znamami, ktor\u00e9 sa odstra\u0148uj\u00fa VACUUM<\/a><\/noindex> (\u010fakujem za inform\u00e1ciu Petrovi Geogheganovi (Peter Geoghegan<\/a><\/noindex>)). Nafukovanie indexov je obzvl\u00e1\u0161\u0165 postrehnute\u013en\u00e9 pri pracovn\u00fdch z\u00e1\u0165a\u017eiach, kde sa index akt\u00edvne men\u00ed.<\/p>\n

<\/p>\n

PostgreSQL 12 v\u00fdrazne zlep\u0161uje v\u00fdkon B-stromov\u00fdch indexov, a experimenty s testami typu TPC-C uk\u00e1zali, \u017ee sa teraz miesto pou\u017e\u00edva v priemere o 40 % menej. Teraz str\u00e1vime menej \u010dasu nielen \u00fadr\u017ebou B-stromov\u00fdch indexov (t.j. pri z\u00e1pisov\u00fdch oper\u00e1ci\u00e1ch), ale aj pri z\u00edskavan\u00ed \u00fadajov, preto\u017ee indexy sa stali ove\u013ea men\u0161\u00edmi.<\/p>\n

<\/p>\n

Aplik\u00e1cie, ktor\u00e9 akt\u00edvne aktualizuj\u00fa svoje tabu\u013eky \u2014 zvy\u010dajne ide o OLTP aplik\u00e1cie (spracovanie transakci\u00ed v re\u00e1lnom \u010dase<\/a><\/noindex>) \u2014 bud\u00fa ove\u013ea efekt\u00edvnej\u0161ie vyu\u017e\u00edva\u0165 disk a spracov\u00e1va\u0165 dopyty. \u010c\u00edm viac miesta je na disku, t\u00fdm v\u00e4\u010d\u0161\u00ed priestor m\u00e1 datab\u00e1za na rast bez upgradu infra\u0161trukt\u00fary.<\/p>\n

<\/p>\n

Niektor\u00e9 strat\u00e9gie upgradu si vy\u017eaduj\u00fa prestavbu B-stromov\u00fdch indexov, aby vyu\u017eili tieto v\u00fdhody (napr\u00edklad, pg_upgrade<\/a><\/noindex> neprestav\u00ed indexy automaticky). V predch\u00e1dzaj\u00facich verzi\u00e1ch PostgreSQL prestavba ve\u013ek\u00fdch indexov v tabu\u013ek\u00e1ch sp\u00f4sobovala zna\u010dn\u00e9 prestoje, preto\u017ee v tom \u010dase nebolo mo\u017en\u00e9 robi\u0165 zmeny. Ale v PostgreSQL 12 je e\u0161te jedna skvel\u00e1 funkcia: teraz je mo\u017en\u00e9 prestavova\u0165 indexy paralelne pr\u00edkazom REINDEX CONCURRENTLY<\/a><\/noindex>, aby sa \u00faplne predi\u0161lo prestojom.<\/p>\n

<\/p>\n

V PostgreSQL 12 s\u00fa aj \u010fal\u0161ie vylep\u0161enia infra\u0161trukt\u00fary indexovania. \u010eal\u0161ia vec, kde sa to nezaobi\u0161lo bez \u010darovania, je \u017eurn\u00e1l predch\u00e1dzaj\u00faceho z\u00e1pisu<\/a><\/noindex>, zn\u00e1my aj ako WAL (write-ahead log). \u017durn\u00e1l predch\u00e1dzaj\u00faceho z\u00e1pisu zaznamen\u00e1va ka\u017ed\u00fa transakciu v PostgreSQL pre pr\u00edpad zlyhania a replik\u00e1cie. Aplik\u00e1cie ho pou\u017e\u00edvaj\u00fa na archiv\u00e1ciu a obnovenie k ur\u010dit\u00e9mu \u010dasu<\/a><\/noindex>. Samozrejme, \u017eurn\u00e1l predch\u00e1dzaj\u00faceho z\u00e1pisu sa zapisuje na disk, \u010do m\u00f4\u017ee ovplyvni\u0165 v\u00fdkon.<\/p>\n

<\/p>\n

V PostgreSQL 12 sa zn\u00ed\u017eili n\u00e1klady na transakcie WAL, ktor\u00e9 vytv\u00e1raj\u00fa indexy GiST, GIN a SP-GiST pri budovan\u00ed indexu. To prin\u00e1\u0161a nieko\u013eko hmatate\u013en\u00fdch v\u00fdhod: z\u00e1znamy WAL zaberaj\u00fa menej miesta na disku a d\u00e1ta sa r\u00fdchlej\u0161ie obnovuj\u00fa, napr\u00edklad pri obnove po zlyhan\u00ed alebo obnove na konkr\u00e9tny \u010das. Ak v svojich aplik\u00e1ci\u00e1ch pou\u017e\u00edvate tak\u00e9to indexy (napr\u00edklad pri geografick\u00fdch aplik\u00e1ci\u00e1ch, ktor\u00e9 na z\u00e1klade PostGIS \u010dasto pou\u017e\u00edvaj\u00fa index GiST), ide o \u010fal\u0161iu funkciu, ktor\u00e1 v\u00fdrazne zlep\u0161\u00ed v\u00fdkon bez ak\u00fdchko\u013evek n\u00e1mahy z va\u0161ej strany.<\/p>\n

<\/p>\n

Particionovanie \u2014 viac, lep\u0161ie, r\u00fdchlej\u0161ie<\/h3>\n

<\/p>\n

V PostgreSQL 10 sa objavilo deklara\u010dn\u00e9 particionovanie<\/a><\/noindex>. V PostgreSQL 11 sa jeho pou\u017e\u00edvanie stalo ove\u013ea jednoduch\u0161ie. V PostgreSQL 12 je mo\u017en\u00e9 meni\u0165 mieru sekci\u00ed.<\/p>\n

<\/p>\n

V PostgreSQL 12 sa v\u00fdkon syst\u00e9mu particionovania zna\u010dne zlep\u0161il, najm\u00e4 ak m\u00e1 tabu\u013eka tis\u00edce sekci\u00ed. Napr\u00edklad, ak dotaz zasahuje len do nieko\u013ek\u00fdch sekci\u00ed v tabu\u013eke, kde ich je tis\u00edc, vykon\u00e1 sa ove\u013ea r\u00fdchlej\u0161ie. V\u00fdkon bol zlep\u0161en\u00fd nielen pre tieto typy dotazov. Taktie\u017e si v\u0161imnete, ako sa ur\u00fdchlili oper\u00e1cie INSERT v tabu\u013ek\u00e1ch s viacer\u00fdmi sekciami.<\/p>\n

<\/p>\n

Zaznamen\u00e1vanie \u00fadajov pomocou KOP\u00cdROVA\u0164<\/a><\/noindex> \u2014 mimochodom, to je skvel\u00fd sp\u00f4sob hromadn\u00e9ho nahr\u00e1vania d\u00e1t<\/a><\/noindex> a tu je pr\u00edklad prijatia JSON<\/a><\/noindex> \u2014 do particionovan\u00fdch tabuliek v PostgreSQL 12 sa tie\u017e stalo efekt\u00edvnej\u0161ie. S COPY to u\u017e bolo r\u00fdchle, a v PostgreSQL 12 je to \u00faplne bleskov\u00e9.<\/p>\n

<\/p>\n

V\u010faka t\u00fdmto v\u00fdhod\u00e1m m\u00f4\u017eeme v PostgreSQL uchov\u00e1va\u0165 e\u0161te v\u00e4\u010d\u0161ie s\u00fabory d\u00e1t, a ich pr\u00edstup sa stal jednoduch\u0161\u00edm. A to bez ak\u00fdchko\u013evek n\u00e1mahy z va\u0161ej strany. Ak m\u00e1 aplik\u00e1cia ve\u013ea sekci\u00ed, napr\u00edklad pri zaznamen\u00e1van\u00ed \u00fadajov o \u010dasov\u00fdch radoch, jednoduch\u00e1 aktualiz\u00e1cia v\u00fdrazne zlep\u0161\u00ed jej v\u00fdkon.<\/p>\n

<\/p>\n

A hoci toto zlep\u0161enie nie je \u00faplne v kateg\u00f3rii \u201eupgrade a te\u0161\u00edme sa\u201c, v PostgreSQL 12 je mo\u017en\u00e9 vytv\u00e1ra\u0165 vonkaj\u0161ie k\u013e\u00fa\u010de, ktor\u00e9 odkazuj\u00fa na particionovan\u00e9 tabu\u013eky, tak\u017ee pr\u00e1ca s particionovan\u00edm sa st\u00e1va skuto\u010dn\u00fdm pote\u0161en\u00edm.<\/p>\n

<\/p>\n

Dotazy WITH sa v\u00fdrazne zlep\u0161ili<\/h3>\n

<\/p>\n

Ke\u010f bol pou\u017eit\u00fd patch pre vlo\u017een\u00e9 generick\u00e9 tabu\u013ekov\u00e9 v\u00fdrazy<\/a><\/noindex> (tie\u017e CTE, tie\u017e dotazy WITH), ve\u013emi som sa te\u0161il nap\u00edsa\u0165 \u010dl\u00e1nok o tom, ako sa v\u00fdvoj\u00e1ri aplik\u00e1ci\u00ed s PostgreSQL pote\u0161ili.<\/a><\/noindex>. Je to jedna z t\u00fdch funkci\u00ed, ktor\u00e9 ur\u00fdchlia aplik\u00e1ciu. Ak samozrejme pou\u017e\u00edvate CTE.<\/p>\n

<\/p>\n

\u010casto si v\u0161imnem, \u017ee nov\u00e1\u010dikovia v SQL radi pou\u017e\u00edvaj\u00fa CTE: ak ich nap\u00ed\u0161ete ur\u010dit\u00fdm sp\u00f4sobom, priamo c\u00edtite, \u017ee p\u00ed\u0161ete imperat\u00edvny program. Osobne som mal r\u00e1d prepisovanie t\u00fdchto dopytov, aby som sa vyhol bez<\/em> CTE a zv\u00fd\u0161il v\u00fdkonnos\u0165. Teraz je v\u0161etko inak.<\/p>\n

<\/p>\n

PostgreSQL 12 umo\u017e\u0148uje vlo\u017ei\u0165 ur\u010dit\u00fd typ CTE bez ved\u013eaj\u0161\u00edch \u00fa\u010dinkov (SELECT<\/code>), ktor\u00fd sa pou\u017e\u00edva iba raz bli\u017e\u0161ie ku koncu dopytu. Keby som evidoval dopyty s CTE, ktor\u00e9 som prepisoval, v\u00e4\u010d\u0161ina z nich by patrila do tejto kateg\u00f3rie. To pom\u00e1ha v\u00fdvoj\u00e1rom p\u00edsa\u0165 zrozumite\u013en\u00fd k\u00f3d, ktor\u00fd teraz e\u0161te aj r\u00fdchlo be\u017e\u00ed.<\/p>\n

<\/p>\n

Navy\u0161e PostgreSQL 12 optimalizuje vykon\u00e1vanie SQL samo, nebudete musie\u0165 robi\u0165 ni\u010d. A hoci u\u017e teraz asi nebudem musie\u0165 optimalizova\u0165 tak\u00e9 dopyty, je skvel\u00e9, \u017ee PostgreSQL na\u010falej pracuje na optimaliz\u00e1cii dopytov.<\/p>\n

<\/p>\n

Just-in-Time (JIT) \u2014 teraz predvolene<\/h3>\n

<\/p>\n

V syst\u00e9moch PostgreSQL 12 s podporou LLVM<\/a><\/noindex> JIT kompil\u00e1cia je zapnut\u00e1 predvolene. Po prv\u00e9, z\u00edskavate podporu JIT<\/a><\/noindex> pre niektor\u00e9 intern\u00e9 oper\u00e1cie, a po druh\u00e9, dopyty s v\u00fdrazmi (najjednoduch\u0161\u00ed pr\u00edklad \u2014 x + y) v zoznamoch v\u00fdberu (ktor\u00e9 m\u00e1te po SELECT), agreg\u00e1tmi, v\u00fdrazmi s podmienkami WHERE a in\u00fdmi m\u00f4\u017eu vyu\u017ei\u0165 JIT pre zv\u00fd\u0161enie v\u00fdkonnosti.<\/p>\n

<\/p>\n

Ke\u010f\u017ee je JIT v PostgreSQL 12 predvolene povolen\u00fd, v\u00fdkonnos\u0165 sa zlep\u0161uje sama osebe, ale odpor\u00fa\u010dam otestova\u0165 aplik\u00e1ciu v PostgreSQL 11, kde sa JIT iba objavil, aby ste zmerali v\u00fdkonnos\u0165 dopytov a zistili, \u010di je potrebn\u00e9 nie\u010do nastavi\u0165.<\/p>\n

<\/p>\n

A ak\u00e9 s\u00fa ostatn\u00e9 nov\u00e9 funkcie PostgreSQL 12?<\/h3>\n

<\/p>\n

V PostgreSQL 12 je mno\u017estvo nov\u00fdch skvel\u00fdch funkci\u00ed \u2014 od mo\u017enosti sk\u00fama\u0165 \u00fadaje JSON pomocou \u0161tandardn\u00fdch v\u00fdrazov cesty SQL\/JSON po viacfaktorov\u00fa autentifik\u00e1ciu s parametrom clientcert=verify-full<\/code>, vytvoren\u00fdch st\u013apcov a mnoho \u010fal\u0161ieho. Sta\u010d\u00ed to na samostatn\u00fd pr\u00edspevok.<\/p>\n

<\/p>\n

Rovnako ako PostgreSQL 10, PostgreSQL 12 zv\u00fd\u0161i celkov\u00fa v\u00fdkonnos\u0165 hne\u010f po upgrade. Samozrejme, m\u00f4\u017eete ma\u0165 svoj vlastn\u00fd pr\u00edstup \u2013 otestujte aplik\u00e1ciu za podobn\u00fdch podmienok v prev\u00e1dzkovom syst\u00e9me predt\u00fdm, ne\u017e aktivujete vylep\u0161enia, ako som to urobil ja s PostgreSQL 10. Aj ke\u010f je PostgreSQL 12 u\u017e teraz stabilnej\u0161\u00ed, ne\u017e som predpokladal, ne\u013eutujte \u010das na kvalitn\u00e9 testovanie aplik\u00e1ci\u00ed pred ich nasaden\u00edm do produkcie.<\/p>\n

Zdroj: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

PostgreSQL 12, \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u044f\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u00ab\u043b\u0443\u0447\u0448\u0435\u0439 \u0432 \u043c\u0438\u0440\u0435 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c\u00bb, \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0443-\u0442\u0440\u043e\u0439\u043a\u0443 \u043d\u0435\u0434\u0435\u043b\u044c (\u0435\u0441\u043b\u0438 \u0432\u0441\u0435 \u043f\u043e\u0439\u0434\u0435\u0442 \u043f\u043e \u043f\u043b\u0430\u043d\u0443). \u042d\u0442\u043e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u0435\u0442 \u043e\u0431\u044b\u0447\u043d\u043e\u043c\u0443 \u0440\u0430\u0441\u043f\u0438\u0441\u0430\u043d\u0438\u044e \u2014 \u043d\u043e\u0432\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u0441 \u0443\u0439\u043c\u043e\u0439 \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0440\u0430\u0437 \u0432 \u0433\u043e\u0434, \u0438, \u0447\u0435\u0441\u0442\u043d\u043e \u0433\u043e\u0432\u043e\u0440\u044f, \u044d\u0442\u043e \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u044f\u0435\u0442. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u044f \u0438 \u0441\u0442\u0430\u043b \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u043c \u0447\u043b\u0435\u043d\u043e\u043c \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0430 PostgreSQL. \u041f\u043e-\u043c\u043e\u0435\u043c\u0443, \u0432 \u043e\u0442\u043b\u0438\u0447\u0438\u0435 \u043e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28500,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37975","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Upgrade pre leniv\u00fdch: ako PostgreSQL 12 zvy\u0161uje v\u00fdkonnos\u0165 | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\u0410\u043f\u0433\u0440\u0435\u0439\u0434 \u0434\u043b\u044f \u043b\u0435\u043d\u0438\u0432\u044b\u0445: \u043a\u0430\u043a PostgreSQL 12 \u043f\u043e\u0432\u044b\u0448\u0430\u0435\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c | ProHoster","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","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-31T19:20:56+00:00","article:modified_time":"2019-10-31T19:20:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37975","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-23 19:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:17:22","updated":"2026-01-23 19:59:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/37975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=37975"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/37975\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/28500"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=37975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=37975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=37975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}