{"id":79039,"date":"2020-04-23T19:43:26","date_gmt":"2020-04-23T17:43:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql"},"modified":"2020-04-23T19:43:26","modified_gmt":"2020-04-23T17:43:26","slug":"ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Nastavljaju\u0107i temu unosa velikih koli\u010dina podataka, pokrenutu <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/497008\/\">prethodnim \u010dlankom o sekcioniranju<\/a><\/noindex>, u ovom \u0107emo razmotriti na\u010dine na koje se mo\u017ee <b>smanjiti \"fizi\u010dka\" veli\u010dina pohranjenih<\/b> u PostgreSQL-u i njihov utjecaj na performanse poslu\u017eitelja.<\/p>\n<p>Govorit \u0107emo o <b>TOAST postavkama i poravnanju podataka<\/b>. \"U prosjeku\" ovi na\u010dini \u0107e omogu\u0107iti u\u0161tedu ne previ\u0161e resursa, ali \u2014 bez modifikacije koda aplikacije.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/4d43b9b43edb10c4c8f13159c7dd1eac.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nMe\u0111utim, na\u0161e iskustvo pokazalo se vrlo produktivnim u tom smislu, jer skladi\u0161te gotovo svakog monitora po svojoj prirodi jest <b>ve\u0107inom append-only<\/b> s obzirom na zapisane podatke. A ako vas zanima kako u\u010diti bazu da pi\u0161e na disk umjesto <b>200MB\/s<\/b> dvostruko manje \u2014 molim, pod cut.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Mali tajni trikovi velikih podataka<\/h2>\n<p>\nPo profilu rada <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/487380\/\">na\u0161e usluge<\/a><\/noindex>, redovito primamo iz logova <b>tekstualne pakete<\/b>.<\/p>\n<p>A budu\u0107i da <noindex><a rel=\"nofollow\" href=\"https:\/\/sbis.ru\/all_services\">sustav SBIS<\/a><\/noindex>, \u010dije baze podataka pratimo, predstavlja vi\u0161ekomponentni proizvod s kompleksnim strukturama podataka, zahtijevaju se <b>za postizanje maksimalne u\u010dinkovitosti<\/b> prili\u010dno takvi <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/486072\/\">\"mnogotomnici\" s slo\u017eenom algoritamskom logikom<\/a><\/noindex>. Tako da i obujam svake pojedina\u010dne instance upita ili rezultantnog plana izvr\u0161enja u dolaznom logu ispadne \"u prosjeku\" dovoljno velik.<\/p>\n<p>Pogledajmo strukturu jedne od tablica, u koju upisujemo \"sirove\" podatke \u2014 odnosno ba\u0161 originalni tekst iz zapisa loga:<\/p>\n<pre><code class=\"sql\">CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- klju\u010d sekcije\n    date\n, data -- najva\u017enije\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n<p>\nTipi\u010dna takva tablica (ve\u0107 sekcionirana, naravno, dakle ovo je \u2014 predlo\u017eak sekcije), gdje je najva\u017enije \u2014 tekst. Ponekad dovoljno obiman.<\/p>\n<p>Podsjetimo se da \"fizi\u010dka\" veli\u010dina jednog zapisa u PG ne mo\u017ee zauzeti vi\u0161e od jedne stranice podataka, no \"logi\u010dka\" veli\u010dina \u2014 sasvim je druga stvar. Da bi se zabilje\u017eio obiman vrijednost u polju (varchar\/text\/bytea) koristi se <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgresql\/12\/storage-toast\">TOAST tehnologija<\/a><\/noindex>:<\/p>\n<blockquote><p>PostgreSQL koristi fiksnu veli\u010dinu stranice (obi\u010dno 8 KB) i ne dopu\u0161ta da tupli zauzimaju vi\u0161e stranica. Stoga nije mogu\u0107e izravno pohranjivati vrlo velike vrijednosti polja. Kako bi se prevladalo ovo ograni\u010denje, velike vrijednosti polja se komprimiraju i\/ili razbijaju na nekoliko fizi\u010dkih redaka. To se doga\u0111a neprimjetno za korisnika i ima minimalan utjecaj na ve\u0107i dio poslu\u017eiteljskog koda. Ova metoda poznata je kao TOAST \u2026<\/p><\/blockquote>\n<p>\nZapravo, za svaku tablicu s \"potencijalno velikim\" poljima automatski <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgresql\/12\/storage-toast#STORAGE-TOAST-ONDISK\">stvara se pripadaju\u0107a tablica s \"narezivanjem\"<\/a><\/noindex> svake \"velike\" zapisa u segmente od 2KB:<\/p>\n<pre><code class=\"sql\">TOAST(\n  chunk_id\n    integer\n, chunk_seq\n    integer\n, chunk_data\n    bytea\n, PRIMARY KEY(chunk_id, chunk_seq)\n);<\/code><\/pre>\n<p>\nTo jest, ako moramo zabilje\u017eiti redak s \"velikom\" vrijedno\u0161\u0107u <code>data<\/code>, tada \u0107e se stvarni zapis dogoditi <b>ne samo u glavnoj tablici i njenom PK, ve\u0107 i u TOAST-u i njenom PK<\/b>.<\/p>\n<h4>Smanjenje TOAST utjecaja<\/h4>\n<p>\nAli ve\u0107ina zapisa kod nas zapravo nije toliko velika, <b>u 8KB bi se trebala uklapati<\/b> \u2014 kako na tome u\u0161tedjeti?..<\/p>\n<p>Ovdje nam poma\u017ee atribut <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgresql\/12\/storage-toast#STORAGE-TOAST-ONDISK\"><code>STORAGE<\/code><\/a><\/noindex> u stupcu tablice:<\/p>\n<blockquote>\n<ul>\n<li><b>EXTENDED<\/b> dozvoljava i kompresiju i odvojeno pohranjivanje. Ovo je <b>standardna opcija<\/b> za ve\u0107inu vrsta podataka kompatibilnih s TOAST-om. Prvo se poku\u0161ava izvr\u0161iti kompresija, zatim \u2014 pohrana izvan tablice, ako redak i dalje ostaje prevelik.<\/li>\n<li><b>MAIN<\/b> dozvoljava kompresiju, ali ne i odvojeno pohranjuvanje. (Zapravo, odvojeno pohranjivanje, ipak, bit \u0107e izvr\u0161eno za takve stupce, ali samo <b>kao krajnja mjera<\/b>, kada nema drugog na\u010dina da se smanji redak tako da stane na stranicu.)<\/li>\n<\/ul>\n<\/blockquote>\n<p>Zapravo, to je upravo ono \u0161to nam treba za tekst \u2014 <b>maksimalno komprimirati, a ako se ba\u0161 ne mo\u017ee smjestiti \u2014 premjestiti u TOAST<\/b>. Ovo se mo\u017ee u\u010diniti odmah \"u letu\", jednom naredbom:<\/p>\n<pre><code class=\"sql\">ALTER TABLE rawdata_orig ALTER COLUMN data SET STORAGE MAIN;<\/code><\/pre>\n<p><\/p>\n<h4>Kako ocijeniti u\u010dinak<\/h4>\n<p>\nBudu\u0107i da se svakodnevni tijek podataka mijenja, ne mo\u017eemo uspore\u0111ivati apsolutne brojke, ali u relativnim, \u0161to <b>manji postotak<\/b> zapisujemo u TOAST \u2014 to je bolje. Ali ovdje postoji opasnost \u2014 \u0161to je ve\u0107i \"fizi\u010dki\" volumen svakog pojedina\u010dnog zapisa, to \"\u0161iri\" postaje indeks, jer se mora pokriti ve\u0107i broj stranica podataka.<\/p>\n<p>Sekcija <b>prije promjena<\/b>:<\/p>\n<pre><code class=\"plaintext\">heap  = 37GB (39%)\nTOAST = 54GB (57%)\nPK    =  4GB ( 4%)\n<\/code><\/pre>\n<p>\nSekcija <b>poslije promjena<\/b>:<\/p>\n<pre><code class=\"plaintext\">heap  = 37GB (67%)\nTOAST = 16GB (29%)\nPK    =  2GB ( 4%)<\/code><\/pre>\n<p>\nZapravo, mi <b>u TOAST-u pi\u0161emo 2 puta rje\u0111e<\/b>, \u0161to je olak\u0161alo ne samo disk, ve\u0107 i CPU:<\/p>\n<p><img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/547485eff9c6491ffe4d59e5c81f656d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/6bd3b18146c20959693f961e41fff447.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nNapominjem da sada i '\u010ditamo' disk manje, ne samo 'pi\u0161emo' \u2014 jer prilikom umetanja zapisa u neku tablicu moramo 'pro\u010ditati' i dio stabla svakog od indeksa kako bismo odredili njegovu budu\u0107u poziciju u njima.<\/p>\n<h2>Onima koji \u017eive dobro s PostgreSQL 11<\/h2>\n<p>\nNakon nadogradnje na PG11 odlu\u010dili smo nastaviti s 'tuningom' TOAST-a i obratili pa\u017enju da je od ove verzije dostupan za konfiguraciju parametar <noindex><a rel=\"nofollow\" href=\"https:\/\/postgrespro.ru\/docs\/postgresql\/11\/storage-toast#STORAGE-TOAST-ONDISK\"><code>toast_tuple_target<\/code><\/a><\/noindex>:<\/p>\n<blockquote><p>Kod obrade TOAST-a aktivira se samo kada je vrijednost retka koja se treba pohraniti u tablici ve\u0107a od TOAST_TUPLE_THRESHOLD bajtova (obi\u010dno je to 2 kB). TOAST kod \u0107e komprimirati i\/ili prenositi vrijednosti polja izvan tablice sve dok vrijednost retka ne postane manja od TOAST_TUPLE_TARGET bajtova (varijabilna veli\u010dina, tako\u0111er obi\u010dno 2 kB) ili dok ne bude mogu\u0107e smanjiti obujam.<\/p><\/blockquote>\n<p>Odlu\u010dili smo da su na\u0161i podaci obi\u010dno ili 'vrlo kratki' ili odmah 'vrlo dugi', pa smo odlu\u010dili ograni\u010diti se na minimalnu mogu\u0107u vrijednost:<\/p>\n<pre><code class=\"sql\">ALTER TABLE rawplan_orig SET (toast_tuple_target = 128);<\/code><\/pre>\n<p>\nPogledajmo kako su nova pode\u0161avanja utjecala na optere\u0107enje diska nakon ponovnog pode\u0161avanja:<\/p>\n<p><img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/ccaa4879e413a566b362d01582eb8c19.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nNije lo\u0161e! Prosje\u010dna <b>\u010dekanja na disk smanjena je<\/b> otprilike 1,5 puta, a 'zauzetost' diska \u2014 za 20%! Ali mo\u017eda je to nekako utjecalo na CPU?<\/p>\n<p><img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/f7026e5809853d35c6fb7a8376b9f369.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nU svakom slu\u010daju, sigurno nije postalo gore. Iako, te\u0161ko je suditi, kada \u010dak i takvi volumeni ne mogu podi\u0107i prosje\u010dno optere\u0107enje CPU iznad <b>5%<\/b>.<\/p>\n<h2>Od promjene mjesta sastojaka zbroj\u2026 se mijenja!<\/h2>\n<p>\nKako je poznato, jedan nov\u010di\u0107 \u0161tedi rubalj, a pri na\u0161im volumenu pohrane od <b>10TB\/mjesec<\/b> \u010dak i mala optimizacija mo\u017ee donijeti dobru korist. Stoga smo obratili pa\u017enju na fizi\u010dku strukturu svojih podataka \u2014 konkretno kako su <b>'ure\u0111eni' polja unutar zapisa<\/b> svake od tablica.<\/p>\n<p>Zato \u0161to zbog <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/postgrespro\/blog\/444536\/\">poravnanja podataka<\/a><\/noindex> to izravno <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.gitlab.com\/ee\/development\/ordering_table_columns.html\">utje\u010de na kona\u010dnu veli\u010dinu<\/a><\/noindex>:<\/p>\n<blockquote><p>Mnoge arhitekture predvi\u0111aju poravnanje podataka po granicama strojnih rije\u010di. Na primjer, na 32-bitnom sistemu x86, cijeli brojevi (tip integer, zauzima 4 bajta) bit \u0107e poravnati po granici 4-bajtnih rije\u010di, kao i brojevi s pomi\u010dnom to\u010dkom duple preciznosti (tip double precision, 8 bajtova). Na 64-bitnom sustavu, double vrijednosti \u0107e biti poravnate po granici 8-bajtnih rije\u010di. To je jo\u0161 jedan razlog nespojivosti.<\/p>\n<p>Zbog poravnanja, veli\u010dina tabli\u010dnog reda ovisi o redoslijedu postavljanja polja. Obi\u010dno taj efekt nije jako primjetan, ali u nekim slu\u010dajevima mo\u017ee dovesti do zna\u010dajnog pove\u0107anja veli\u010dine. Na primjer, ako se polja tipa char(1) i integer mije\u0161aju, obi\u010dno \u0107e izme\u0111u njih propadati 3 bajta bez potrebe.<\/p><\/blockquote>\n<p>\nZapo\u010dnimo sa sinteti\u010dkim modelima:<\/p>\n<pre><code class=\"sql\">SELECT pg_column_size(ROW(\n  '0000-0000-0000-0000-0000-0000-0000-0000'::uuid\n, 0::smallint\n, '2019-01-01'::date\n));\n-- 48 bajtova\n\nSELECT pg_column_size(ROW(\n  '2019-01-01'::date\n, '0000-0000-0000-0000-0000-0000-0000-0000'::uuid\n, 0::smallint\n));\n-- 46 bajtova<\/code><\/pre>\n<p>\nOdakle su do\u0161la dva suvi\u0161na bajta u prvom slu\u010daju? Sve je jednostavno \u2014 <b>2-bajtni smallint se poravnava na 4-bajtnoj granici<\/b> ispred sljede\u0107eg polja, dok kada je posljednje \u2014 nema potrebu za poravnanjem.<\/p>\n<p>U teoriji \u2014 sve je dobro i mo\u017ee se preure\u0111ivati polja kako god \u017eelite. Provjerimo na stvarnim podacima uz primjer jedne od tablica, \u010dija dnevna sekcija zauzima oko 10-15GB.<\/p>\n<p>Izvorna struktura:<\/p>\n<pre><code class=\"sql\">CREATE TABLE public.plan_20190220\n(\n-- Naslije\u0111eno iz tablice plan:  pack uuid NOT NULL,\n-- Naslije\u0111eno iz tablice plan:  recno smallint NOT NULL,\n-- Naslije\u0111eno iz tablice plan:  host uuid,\n-- Naslije\u0111eno iz tablice plan:  ts timestamp with time zone,\n-- Naslije\u0111eno iz tablice plan:  exectime numeric(32,3),\n-- Naslije\u0111eno iz tablice plan:  duration numeric(32,3),\n-- Naslije\u0111eno iz tablice plan:  bufint bigint,\n-- Naslije\u0111eno iz tablice plan:  bufmem bigint,\n-- Naslije\u0111eno iz tablice plan:  bufdsk bigint,\n-- Naslije\u0111eno iz tablice plan:  apn uuid,\n-- Naslije\u0111eno iz tablice plan:  ptr uuid,\n-- Naslije\u0111eno iz tablice plan:  dt date,\n  CONSTRAINT plan_20190220_pkey PRIMARY KEY (pack, recno),\n  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),\n  CONSTRAINT plan_20190220_dt_check CHECK (dt = '2019-02-20'::date)\n)\nINHERITS (public.plan)<\/code><\/pre>\n<p>\nSekcija nakon promjene redoslijeda kolona \u2014 to\u010dno <b>iste polja, samo u druga\u010dijem redoslijedu<\/b>:<\/p>\n<pre><code class=\"sql\">CREATE TABLE public.plan_20190221\n(\n-- Naslije\u0111eno iz tablice plan:  dt date NOT NULL,\n-- Naslije\u0111eno iz tablice plan:  ts timestamp with time zone,\n-- Naslije\u0111eno iz tablice plan:  pack uuid NOT NULL,\n-- Naslije\u0111eno iz tablice plan:  recno smallint NOT NULL,\n-- Naslije\u0111eno iz tablice plan:  host uuid,\n-- Naslije\u0111eno iz tablice plan:  apn uuid,\n-- Naslije\u0111eno iz tablice plan:  ptr uuid,\n-- Naslije\u0111eno iz tablice plan:  bufint bigint,\n-- Naslije\u0111eno iz tablice plan:  bufmem bigint,\n-- Naslije\u0111eno iz tablice plan:  bufdsk bigint,\n-- Naslije\u0111eno iz tablice plan:  exectime numeric(32,3),\n-- Naslije\u0111eno iz tablice plan:  duration numeric(32,3),\n  CONSTRAINT plan_20190221_pkey PRIMARY KEY (pack, recno),\n  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),\n  CONSTRAINT plan_20190221_dt_check CHECK (dt = '2019-02-21'::date)\n)\nINHERITS (public.plan)<\/code><\/pre>\n<p>\nUkupna veli\u010dina sekcije odre\u0111uje se brojem \"doga\u0111aja\" i ovisi isklju\u010divo o vanjskim procesima, stoga \u0107emo podijeliti veli\u010dinu heap (<code>pg_relation_size<\/code>) o broju zapisa u njemu \u2014 \u0161to \u0107emo dobiti <b>prosje\u010dnu veli\u010dinu stvarno pohranjenog zapisa<\/b>:<\/p>\n<p><img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/06be2d7d70d223e7678f9a478e4c293f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Minus 6% volumena<\/b>, odli\u010dan!<\/p>\n<p>Ali, naravno, nije sve tako ru\u017ei\u010dasto \u2014 jer <b>u indeksima ne mo\u017eemo promijeniti redoslijed polja<\/b>, a stoga je 'ukupno' (<code>pg_total_relation_size<\/code>)\u2026<\/p>\n<p><img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/8beff38e5034fc0d40665b75cb3b3625.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n\u2026 ipak i ovdje <b>u\u0161tedjeli 1.5%<\/b>, ne promijeniv\u0161i niti jedan redak koda. Ta\u010dno!<\/p>\n<p><img decoding=\"async\" alt=\"\u0160tedimo novac na velikim koli\u010dinama u PostgreSQL-u\" src=\"\/wp-content\/uploads\/2020\/04\/10f4a2151465a38bf45823a5d360302b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Napominjem da prethodna varijanta rasporeda polja \u2014 nije nu\u017eno najsvjetlija. Jer neke grupe polja ne \u017eelimo 'razdvajati' \u010dak ni iz estetskih razloga \u2014 na primjer, par <code>(pack, recno)<\/code>, koji je PK za ovu tablicu.<\/p>\n<p>U cjelini, definiranje 'minimalnog' rasporeda polja \u2014 to je prili\u010dno jednostavan 'povratni' zadatak. Stoga mo\u017eete dobiti rezultate koji su \u010dak bolji od na\u0161ih na svojim podacima \u2014 probajte!<br \/>\n<br \/>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/tensor\/blog\/498292\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u0437\u0430\u043f\u0438\u0441\u0438 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043f\u043e\u0442\u043e\u043a\u043e\u0432 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u043e\u0434\u043d\u044f\u0442\u0443\u044e \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043f\u0440\u043e \u0441\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0432 \u044d\u0442\u043e\u0439 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u043f\u043e\u0441\u043e\u0431\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u043c\u0438 \u043c\u043e\u0436\u043d\u043e \u0443\u043c\u0435\u043d\u044c\u0448\u0438\u0442\u044c \u00ab\u0444\u0438\u0437\u0438\u0447\u0435\u0441\u043a\u0438\u0439\u00bb \u0440\u0430\u0437\u043c\u0435\u0440 \u0445\u0440\u0430\u043d\u0438\u043c\u043e\u0433\u043e \u0432 PostgreSQL, \u0438 \u0438\u0445 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 \u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0441\u0435\u0440\u0432\u0435\u0440\u0430. \u0420\u0435\u0447\u044c \u043f\u043e\u0439\u0434\u0435\u0442 \u043f\u0440\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 TOAST \u0438 \u0432\u044b\u0440\u0430\u0432\u043d\u0438\u0432\u0430\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445. \u00ab\u0412 \u0441\u0440\u0435\u0434\u043d\u0435\u043c\u00bb \u044d\u0442\u0438 \u0441\u043f\u043e\u0441\u043e\u0431\u044b \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0442 \u0441\u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0442\u044c \u043d\u0435 \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u043c\u043d\u043e\u0433\u043e \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432, \u0437\u0430\u0442\u043e \u2014 \u0432\u043e\u043e\u0431\u0449\u0435 \u0431\u0435\u0437 \u043c\u043e\u0434\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043a\u043e\u0434\u0430 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u041e\u0434\u043d\u0430\u043a\u043e, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":79040,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-79039","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=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u0437\u0430\u043f\u0438\u0441\u0438 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043f\u043e\u0442\u043e\u043a\u043e\u0432 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u043e\u0434\u043d\u044f\u0442\u0443\u044e \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043f\u0440\u043e \u0441\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0432 \u044d\u0442\u043e\u0439 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u043f\u043e\u0441\u043e\u0431\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u043c\u0438 \u043c\u043e\u0436\u043d\u043e.\" \/>\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\/hr\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-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=\"hr_HR\" \/>\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\u042d\u043a\u043e\u043d\u043e\u043c\u0438\u043c \u043a\u043e\u043f\u0435\u0435\u0447\u043a\u0443 \u043d\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043e\u0431\u044a\u0435\u043c\u0430\u0445 \u0432 PostgreSQL | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u0437\u0430\u043f\u0438\u0441\u0438 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043f\u043e\u0442\u043e\u043a\u043e\u0432 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u043e\u0434\u043d\u044f\u0442\u0443\u044e \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043f\u0440\u043e \u0441\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0432 \u044d\u0442\u043e\u0439 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u043f\u043e\u0441\u043e\u0431\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u043c\u0438 \u043c\u043e\u0436\u043d\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-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=\"2020-04-23T17:43:26+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-23T17:43:26+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\udd47\u0160tedimo nov\u010di\u0107 na velikim volumenima u PostgreSQL | ProHoster","description":"Nastavljaju\u0107i temu snimanja velikih tokova podataka, koju je pokrenuo prethodni \u010dlanak o particioniranju, ovdje \u0107emo razmotriti na\u010dine na koje to mo\u017eemo.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\u042d\u043a\u043e\u043d\u043e\u043c\u0438\u043c \u043a\u043e\u043f\u0435\u0435\u0447\u043a\u0443 \u043d\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043e\u0431\u044a\u0435\u043c\u0430\u0445 \u0432 PostgreSQL | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u0437\u0430\u043f\u0438\u0441\u0438 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043f\u043e\u0442\u043e\u043a\u043e\u0432 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u043e\u0434\u043d\u044f\u0442\u0443\u044e \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043f\u0440\u043e \u0441\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0432 \u044d\u0442\u043e\u0439 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u043f\u043e\u0441\u043e\u0431\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u043c\u0438 \u043c\u043e\u0436\u043d\u043e.","og:url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-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":"2020-04-23T17:43:26+00:00","article:modified_time":"2020-04-23T17:43:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"79039","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:46:33","updated":"2022-09-28 06:02:32","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/79039","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=79039"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/79039\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/79040"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=79039"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=79039"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=79039"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}