{"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\/it\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","title":{"rendered":"Aggiornamento per pigri: come PostgreSQL 12 migliora le prestazioni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Aggiornamento per pigri: come PostgreSQL 12 migliora le prestazioni\" src=\"\/wp-content\/uploads\/2019\/09\/59721c53412b5932a332bd6c687650e8.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/\">PostgreSQL 12<\/a><\/noindex>, l'ultima versione \"del migliore sistema di database relazionale open source al mondo\", uscir\u00e0 tra un paio di settimane (se tutto va secondo i piani). Questo \u00e8 in linea con il consueto programma \u2014 una nuova versione con un sacco di nuove funzionalit\u00e0 viene rilasciata una volta all'anno e, a dire il vero, \u00e8 impressionante. Per questo sono diventato un membro attivo della comunit\u00e0 PostgreSQL.<\/p>\n<p><\/p>\n<p>A mio parere, a differenza delle versioni precedenti, PostgreSQL 12 non introduce una o due funzionalit\u00e0 rivoluzionarie (come ad esempio il partizionamento o il parallelismo delle query). Ho scherzato dicendo che la vera novit\u00e0 di PostgreSQL 12 \u00e8 una maggiore stabilit\u00e0. E non \u00e8 forse ci\u00f2 che serve quando gestisci dati critici per il tuo business?<\/p>\n<p><\/p>\n<p>Ma PostgreSQL 12 non si ferma qui: con nuove funzionalit\u00e0 e miglioramenti, le applicazioni funzioneranno meglio, <em>e a te baster\u00e0 fare un aggiornamento!<\/em><\/p>\n<p><\/p>\n<p>(Beh, forse anche ripristinare gli indici, ma in questa versione non \u00e8 cos\u00ec problematico come ci aspettavamo.)<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Sar\u00e0 fantastico aggiornare PostgreSQL e godere immediatamente di miglioramenti significativi senza troppe complicazioni. Qualche anno fa ho analizzato l'aggiornamento da PostgreSQL 9.4 a PostgreSQL 10 e ho visto come l\u2019applicazione sia stata accelerata grazie al migliorato parallelismo delle query in PostgreSQL 10. E, cosa pi\u00f9 importante, non ho dovuto fare quasi nulla (solo impostare un parametro di configurazione <code>max_parallel_workers<\/code>).<\/p>\n<p><\/p>\n<p>Concordi che \u00e8 comodo quando, subito dopo l'aggiornamento, le applicazioni funzionano meglio. E ci impegniamo molto per rendere felici gli utenti, perch\u00e9 PostgreSQL continua ad avere sempre pi\u00f9 fan.<\/p>\n<p><\/p>\n<p>E come un semplice aggiornamento a PostgreSQL 12 ti render\u00e0 felice? Adesso te lo racconto.<\/p>\n<p><\/p>\n<h3 id=\"sereznye-uluchsheniya-indeksirovaniya\">Importanti miglioramenti nell'indicizzazione<\/h3>\n<p><\/p>\n<p>Senza indicizzazione, un database non andr\u00e0 lontano. Come altrimenti possiamo trovare rapidamente le informazioni? Il sistema di indicizzazione fondamentale di PostgreSQL si chiama <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/B-tree\">B-albero<\/a><\/noindex>. Questo tipo di indice \u00e8 ottimizzato per i sistemi di archiviazione.<\/p>\n<p><\/p>\n<p>Basta utilizzare l'operatore <code>CREATE INDEX ON some_table (some_column)<\/code>, e PostgreSQL si occupa del resto, mantenendo l'indice aggiornato mentre noi continuiamo ad inserire, aggiornare ed eliminare valori. Funziona tutto da solo, come per magia.<\/p>\n<p><\/p>\n<p>Ma gli indici di PostgreSQL hanno un problema \u2014 essi <noindex><a rel=\"nofollow\" href=\"https:\/\/info.crunchydata.com\/blog\/checking-for-postgresql-bloat\">si gonfiano<\/a><\/noindex> e occupano spazio inutile su disco, mentre le prestazioni di estrazione e aggiornamento dei dati diminuiscono. Con \"gonfiamento\" intendo il mantenimento inefficace della struttura dell'indice. Questo pu\u00f2 essere \u2014 e pu\u00f2 anche non essere \u2014 correlato a tuple spazzatura, che vengono eliminate <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/sql-vacuum.html\">VACUUM<\/a><\/noindex> (grazie per l'informazione a Peter Geoghegan (<noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/petervgeoghegan\">Peter Geoghegan<\/a><\/noindex>)). Il gonfiamento dell'indice \u00e8 particolarmente evidente nei carichi di lavoro in cui l'indice viene modificato attivamente.<\/p>\n<p><\/p>\n<p>PostgreSQL 12 migliora significativamente la gestione degli indici B-tree, e gli esperimenti con test di tipo TPC-C hanno mostrato che ora si utilizza, in media, il 40% in meno di spazio. Ora dedichiamo meno tempo non solo alla manutenzione degli indici B-tree (cio\u00e8 alle operazioni di scrittura), ma anche all'estrazione dei dati, poich\u00e9 gli indici sono diventati molto pi\u00f9 piccoli.<\/p>\n<p><\/p>\n<p>Le applicazioni che aggiornano attivamente le proprie tabelle \u2014 di solito sono applicazioni OLTP (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Online_transaction_processing\">elaborazione delle transazioni in tempo reale<\/a><\/noindex>) \u2014 utilizzeranno il disco in modo molto pi\u00f9 efficiente e gestiranno le richieste. Pi\u00f9 spazio c'\u00e8 su disco, maggiore \u00e8 lo spazio a disposizione del database per crescere senza eseguire un aggiornamento dell'infrastruttura.<\/p>\n<p><\/p>\n<p>Alcune strategie di aggiornamento richiedono di ricostruire gli indici B-tree per sfruttare questi vantaggi (ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/pgupgrade.html\">pg_upgrade<\/a><\/noindex> non ricostruisce automaticamente gli indici). Nelle versioni precedenti di PostgreSQL, la ricostruzione di grandi indici nelle tabelle portava a un notevole fermo, poich\u00e9 non era possibile apportare modifiche nel frattempo. Ma in PostgreSQL 12 c'\u00e8 un'altra funzionalit\u00e0 interessante: ora \u00e8 possibile ricostruire gli indici in parallelo con il comando <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/12\/sql-reindex.html\">REINDEX CONCURRENTLY<\/a><\/noindex>, per evitare del tutto il fermo.<\/p>\n<p><\/p>\n<p>In PostgreSQL 12 ci sono anche ulteriori miglioramenti all'infrastruttura di indicizzazione. Un'altra cosa che non \u00e8 stata priva di magia \u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/wal-intro.html\">il log delle scritture anticipate<\/a><\/noindex>, noto anche come WAL (write-ahead log). Il log delle scritture anticipate registra ogni transazione in PostgreSQL per situazioni di fallimento e replicazione. Le applicazioni lo utilizzano per l'archiviazione e <noindex><a rel=\"nofollow\" href=\"https:\/\/info.crunchydata.com\/blog\/pgbackrest-point-in-time-recovery-using-crunchy-postgresql-operator\">il ripristino a un momento specifico<\/a><\/noindex>. Certo, il log delle scritture anticipate viene registrato su disco, e questo pu\u00f2 influire sulle prestazioni.<\/p>\n<p><\/p>\n<p>In PostgreSQL 12, i costi delle registrazioni WAL, creati dagli indici GiST, GIN e SP-GiST durante la creazione degli indici, sono diminuiti. Questo offre diversi vantaggi tangibili: le registrazioni WAL occupano meno spazio su disco e i dati vengono riprodotti pi\u00f9 velocemente, ad esempio durante il ripristino dopo un guasto o il recupero a un determinato momento. Se utilizzi questi indici nelle tue applicazioni (ad esempio, le applicazioni geospaziali basate su PostGIS utilizzano molto l'indice GiST), questa \u00e8 un'altra funzionalit\u00e0 che migliorer\u00e0 notevolmente le prestazioni senza alcuno sforzo da parte tua.<\/p>\n<p><\/p>\n<h3 id=\"sekcionirovanie--bolshe-luchshe-bystree\">Partizionamento \u2014 pi\u00f9 grande, migliore, pi\u00f9 veloce<\/h3>\n<p><\/p>\n<p>In PostgreSQL 10 \u00e8 stato introdotto <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/ddl-partitioning.html\">il partizionamento dichiarativo<\/a><\/noindex>. In PostgreSQL 11 \u00e8 diventato molto pi\u00f9 facile da utilizzare. In PostgreSQL 12 \u00e8 possibile modificare la scala delle partizioni.<\/p>\n<p><\/p>\n<p>In PostgreSQL 12, le prestazioni del sistema di partizionamento sono migliorate notevolmente, specialmente se nella tabella ci sono migliaia di partizioni. Ad esempio, se una query colpisce solo alcune partizioni in una tabella con migliaia di esse, verr\u00e0 eseguita molto pi\u00f9 velocemente. Le prestazioni sono migliorate non solo per questo tipo di query. Noterai anche come siano state accelerate le operazioni INSERT nelle tabelle con molte partizioni.<\/p>\n<p><\/p>\n<p>Scrivere dati usando <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/sql-copy.html\">COPY<\/a><\/noindex> \u2014 a proposito, \u00e8 un ottimo modo <noindex><a rel=\"nofollow\" href=\"https:\/\/info.crunchydata.com\/blog\/fast-csv-and-json-ingestion-in-postgresql-with-copy\">per il caricamento massivo dei dati<\/a><\/noindex> ecco un esempio <noindex><a rel=\"nofollow\" href=\"https:\/\/info.crunchydata.com\/blog\/fast-csv-and-json-ingestion-in-postgresql-with-copy\">di ricezione JSON<\/a><\/noindex> \u2014 anche nelle tabelle partizionate in PostgreSQL 12 \u00e8 diventato pi\u00f9 efficiente. Con COPY era gi\u00e0 tutto veloce, ma in PostgreSQL 12 \u00e8 davvero fulmineo.<\/p>\n<p><\/p>\n<p>Grazie a questi vantaggi, in PostgreSQL \u00e8 possibile memorizzare set di dati di dimensioni ancora maggiori, e l'estrazione \u00e8 diventata pi\u00f9 semplice. E senza alcuno sforzo da parte tua. Se l'applicazione ha molte partizioni, ad esempio, se registra dati di serie temporali, un semplice aggiornamento migliorer\u00e0 notevolmente le sue prestazioni.<\/p>\n<p><\/p>\n<p>E anche se questo miglioramento non rientra esattamente nella categoria 'abbiamo aggiornato e siamo felici', in PostgreSQL 12 \u00e8 possibile creare chiavi esterne che fanno riferimento a tabelle partizionate, in modo che lavorare con il partizionamento sia un vero piacere.<\/p>\n<p><\/p>\n<h3 id=\"zaprosy-with-stali-gorazdo-luchshe\">Le query WITH sono migliorate notevolmente<\/h3>\n<p><\/p>\n<p>Quando <noindex><a rel=\"nofollow\" href=\"https:\/\/git.postgresql.org\/gitweb\/?p=postgresql.git;a=commitdiff;h=608b167f9f9c4553c35bb1ec0eab9ddae643989b\">\u00e8 stata applicata la patch per le espressioni di tabella comuni integrate<\/a><\/noindex> (che sono anche CTE, ovvero le query WITH), non vedevo l'ora di scrivere un articolo su come si sono rallegrati gli sviluppatori di applicazioni con PostgreSQL <noindex><a rel=\"nofollow\" href=\"https:\/\/info.crunchydata.com\/blog\/with-queries-present-future-common-table-expressions\">. Questa \u00e8 una di quelle funzionalit\u00e0 che velocizzeranno l'applicazione. Se, naturalmente, utilizzi i CTE.<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Spesso noto che i principianti in SQL amano usare CTE: se li scrivi in un certo modo, senti davvero che stai scrivendo un programma imperativo. Personalmente, mi piaceva riscrivere queste query per evitarle <em>senza<\/em> CTE e migliorare le prestazioni. Ora tutto \u00e8 diverso.<\/p>\n<p><\/p>\n<p>PostgreSQL 12 consente di incorporare un certo tipo di CTE senza effetti collaterali (<code>SELECT<\/code>), che viene utilizzato solo una volta verso la fine della query. Se avessi tenuto statistiche delle query con CTE che ho riscritto, la maggior parte di esse rientrerebbe in questa categoria. Questo aiuta gli sviluppatori a scrivere codice comprensibile, che ora funziona anche rapidamente.<\/p>\n<p><\/p>\n<p>Inoltre, PostgreSQL 12 ottimizza l'esecuzione SQL automaticamente, non dovrai fare nulla. E sebbene ora, probabilmente, non avr\u00f2 bisogno di ottimizzare queste query, \u00e8 fantastico che PostgreSQL continui a lavorare sull'ottimizzazione delle query.<\/p>\n<p><\/p>\n<h3 id=\"just-in-time-jit--teper-po-umolchaniyu\">Just-in-Time (JIT) \u2014 ora di default<\/h3>\n<p><\/p>\n<p>Nei sistemi PostgreSQL 12 che supportano <noindex><a rel=\"nofollow\" href=\"https:\/\/llvm.org\/\">LLVM<\/a><\/noindex> la compilazione JIT \u00e8 attivata di default. Prima di tutto, ottieni supporto <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/jit.html\">JIT<\/a><\/noindex> per alcune operazioni interne, e in secondo luogo, le query con espressioni (l'esempio pi\u00f9 semplice \u00e8 x + y) nelle liste di selezione (che hai dopo SELECT), aggregati, espressioni con clausole WHERE e altro possono utilizzare JIT per migliorare le prestazioni.<\/p>\n<p><\/p>\n<p>Poich\u00e9 JIT \u00e8 abilitato di default in PostgreSQL 12, le prestazioni miglioreranno da sole, ma ti consiglio di testare l'applicazione in PostgreSQL 11, dove JIT \u00e8 apparso per la prima volta, per misurare le prestazioni delle query e capire se c'\u00e8 bisogno di qualche configurazione.<\/p>\n<p><\/p>\n<h3 id=\"a-kak-zhe-ostalnye-novye-fichi-postgresql-12\">E le altre nuove funzionalit\u00e0 di PostgreSQL 12?<\/h3>\n<p><\/p>\n<p>In PostgreSQL 12 ci sono molte nuove funzionalit\u00e0 interessanti \u2014 dalla possibilit\u00e0 di esplorare i dati JSON utilizzando le espressioni standard SQL\/JSON fino all'autenticazione a pi\u00f9 fattori con il parametro <code>clientcert=verify-full<\/code>, colonne generate e molto altro. Abbastanza per un post a parte.<\/p>\n<p><\/p>\n<p>Come per PostgreSQL 10, PostgreSQL 12 migliorer\u00e0 le prestazioni generali subito dopo l'upgrade. Certo, potresti avere il tuo percorso \u2014 testa l'applicazione in condizioni simili in un ambiente di produzione, prima di attivare i miglioramenti, come ho fatto io con PostgreSQL 10. Anche se PostgreSQL 12 \u00e8 gi\u00e0 ora pi\u00f9 stabile di quanto avessi previsto, non scordarti di testare accuratamente le applicazioni prima di metterle in produzione.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/466727\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>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 [&hellip;]<\/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<!-- All in One SEO 5.0.1.1 - aioseo.com -->\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\/it\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\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\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost\" \/>\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-31T19:20:56+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:20:56+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\udd47Aggiornamento per pigri: come PostgreSQL 12 migliora le prestazioni | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/37975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=37975"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37975\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28500"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=37975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=37975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=37975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}