abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 22:44 | Nová verze

Po třech měsících vývoje od vydání verze 5.5.0 byla vydána verze 5.6.0 správce digitálních fotografií digiKam (digiKam Software Collection). Do digiKamu se mimo jiné vrátila HTML galerie a nástroj pro vytváření videa z fotografií. V Bugzille bylo uzavřeno více než 81 záznamů.

Ladislav Hagara | Komentářů: 0
dnes 17:44 | Nová verze

Byla vydána verze 9.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
dnes 13:53 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2017-06-21 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Z novinek lze zdůraznit IDE Thonny pro vývoj v programovacím jazyce Python a především offline verzi Scratche 2.0. Ten bylo dosud možné používat pouze online. Offline bylo možné používat pouze Scratch ve verzi 1.4. Z nového Scratchu lze ovládat také GPIO piny. Scratch 2.0 vyžaduje Flash.

Ladislav Hagara | Komentářů: 0
včera 14:24 | Nová verze

Opera 46, verze 46.0.2597.26, byla prohlášena za stabilní. Nejnovější verze tohoto webového prohlížeče je postavena na Chromiu 59. Z novinek lze zmínit například podporu APNG (Animated Portable Network Graphics). Přehled novinek pro vývojáře na blogu Dev.Opera. Oznámení o vydání zmiňuje také první televizní reklamu.

Ladislav Hagara | Komentářů: 0
včera 13:37 | IT novinky

I čtenáři AbcLinuxu před dvěma lety vyplňovali dotazníky věnované Retro ThinkPadu. Nyní bylo potvrzeno, že iniciativa Retro ThinkPad je stále naživu a Lenovo připravuje speciální edici ThinkPadu jako součást oslav jeho 25. výročí.

Ladislav Hagara | Komentářů: 16
včera 10:22 | Komunita

Bylo oznámeno, že frontend a runtime programovacího jazyka D bude začleněn do kolekce kompilátorů GCC (GNU Compiler Collection). Správcem byl ustanoven Iain Buclaw.

Ladislav Hagara | Komentářů: 7
21.6. 18:47 | IT novinky
Bulharská firma Olimex je známá jako výrobce kvalitních mini arm desek, u nichž se snaží být maximálně open source. Kromě velké otevřenosti taktéž zaručují dlouhodobou podporu výroby, což je vítáno ve firemním prostředí. Nyní firma ohlásila ESP32-GATEWAY, malou IoT desku s Wifi, Bluetooth, Ethernetem a 20 GPIO porty za 22EUR. Tato malá deska je ořezanou verzí ESP32-EVB.
Max | Komentářů: 21
21.6. 18:00 | Zajímavý článek

LinuxGizmos (v dubnu loňského roku přejmenován na HackerBoards a v lednu letošního roku zpět na LinuxGizmos) zveřejnil výsledky čtenářské ankety o nejoblíbenější jednodeskový počítač (SBC) v roce 2017. Letos se vybíralo z 98 jednodeskových počítačů (Tabulky Google). Nejoblíbenějšími jednodeskovými počítači v letošním roce jsou Raspberry Pi 3 Model B, Raspberry Pi Zero W a Raspberry Pi 2 Model B.

Ladislav Hagara | Komentářů: 0
21.6. 14:22 | Pozvánky

Ne-konference jOpenSpace 2017 se koná od 13. do 15. října 2017 v hotelu Farma u Pelhřimova. Registrace účastníků je nutná. Více informací na stránkách ne-konference.

Zdenek H. | Komentářů: 0
21.6. 14:11 | Nová verze

Vyšla nová verze 1.2 audio kodeku Opus, která přináší mnoho drobných optimalizací a tím i celkové vylepšení poměru bitrate/kvalita. Fullband (do 20 kHz) stereo hudba je možná již od 32 kbit/s, fullband mono řeč již od 14 kbit/s. Více informací sepsal vývojář Opusu J. M. Valin formou již tradiční demo stránky.

Petr Tomášek | Komentářů: 21
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (31%)
 (1%)
 (9%)
 (44%)
 (9%)
Celkem 824 hlasů
 Komentářů: 65, poslední 1.6. 19:16
    Rozcestník

    Dotaz: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci

    23.3.2012 01:49 u-rob-o-ros
    Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Přečteno: 570×
    Ahoj. Potřebuju vyhledávat v obrovské tabulce záznamy, které obsahují třeba na 3. pozici ve sloupci písmeno x, tj.
    sl1 sl2
    1   --xDas
    2   a-xas
    3   --x--
    
    Udělat to pomocí LIKE trvá strašně dlouho, proto bych rád věděl, zda to jde udělat indexovaně? Je mi víceméně jedno jestli se bude hledat třeba podle sloupce typu VARCHAR či např. podle INTu, kde by se hledalo binární operací AND, ale potřebuju na to vytvořit a používat indexy. Jak na to?

    Odpovědi

    okbob avatar 23.3.2012 05:39 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    v 9.1 lze pouzit trigramy a indexovat i like, kde je zolik vlevo.

    Jinak asi by bylo mozne navrhnout i neco efektivnejsiho, ale vyzadovalo by to vlastni typ indexu - a vicemene psani v C. Pak by to asi mohlo byt opravdu efektivni

    Pripadne si pro kazdou pozici muzete udelat index - ale nejde to tak jak si predstavujete.
    CREATE TABLE foo(s text);
    CREATE INDEX ON foo USING GIN ((substring(s FROM 1 FOR 1));
    CREATE INDEX ON foo USING GIN ((substring(s FROM 2 FOR 1));
    CREATE INDEX ON foo USING GIN ((substring(s FROM 3 FOR 1));
    
    SELECT * FROM foo WHERE substring(s FROM 3 FOR 1) = 'x';
    
    tahle podminka bude mit dost mizernou selectivitu - dost mozna ze problem je jenom v like a stacilo by nepouzivat like
    SELECT * FROM foo WHERE substring(s FROM 3 FOR 1) = 'x';
    
    Jeste by slo pouzit hstore:
    postgres=# create or replace function pack(text)
    returns hstore as $$
    SELECT string_agg(i || '=>' || substring($1 FROM i FOR 1),',')::hstore 
    FROM generate_series(1,length($1)) g(i); $$ 
    LANGUAGE sql IMMUTABLE;
    CREATE FUNCTION
    postgres=# select pack('Pavel');
                           pack                       
    --------------------------------------------------
     "1"=>"P", "2"=>"a", "3"=>"v", "4"=>"e", "5"=>"l"
    (1 row)
    
    postgres=# select * from xx;
       a   
    -------
     Pavel
    (1 row)
    
    postgres=# CREATE INDEX ON xx USING GIN((pack(a)));
    CREATE INDEX
    
    postgres=# SELECT * FROM xx WHERE pack(a) @> '3=>v';
       a   
    -------
     Pavel
    (1 row)
    
    postgres=# set enable_seqscan to off;
    SET
    postgres=# explain SELECT * FROM xx WHERE pack(a) @> '3=>v';
                                    QUERY PLAN                                 
    ---------------------------------------------------------------------------
     Bitmap Heap Scan on xx  (cost=12.25..16.51 rows=1 width=32)
       Recheck Cond: (pack(a) @> '"3"=>"v"'::hstore)
       ->  Bitmap Index Scan on xx_pack_idx  (cost=0.00..12.25 rows=1 width=0)
             Index Cond: (pack(a) @> '"3"=>"v"'::hstore)
    (4 rows)
    
    postgres=# SELECT * FROM xx WHERE pack(a) @> '3=>v, 4=>e';
       a   
    -------
     Pavel
    (1 row)
    
    postgres=# SELECT * FROM xx WHERE pack(a) @> '3=>v, 4=>x';
     a 
    ---
    (0 rows)
    
    Ale co bude rychlejsi netusim - hstore je hodne genericky, takze pokud by tam byla nizka selectivita, tak by to nemuselo byt efektivni
    23.3.2012 09:19 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    To vypadá, že v tom textu jsou zakódovaná nějaká data. Databázově nejčistší by bylo ta data rozkódovat a uložit samostatně – třeba i pravidlem při insertu a updatu. Pak už si můžete udělat indexy na ta rozdělená data.
    23.3.2012 09:36 camel1cz | skóre: 23
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci

    Souhlas... a nebo jít cestou oindexování volání funkce - viz CREATE INDEX, je tam příklad na vytvoření indexu nad lower()

    23.3.2012 10:21 u-rob-o-ros
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Víceméně se snažím vyhnout použití 2 tabulek a časově náročnému spojování po každém dotazu nebo částečné redundanci. Abych upřesnil co to má dělat: mám N měřících stanic, jejichž počet se občas mění. Každá stanice ukládá do tabulky každou vteřinu měření. Měření jsou často naprosto identická a proto se snažím uspořit data tím, že místo 10 skoro identických řádků uložím jeden, který bude mít speciální rozlišovací sloupec určující jednotlivé stanice. Ten sloupec by byl třeba znakový "xxx-xxx-" (data jsou stejná pro 1. 2. 3. 5. 6. a 7. stanici) nebo celočíselný používající k rozlišení boolovskou algrebru (1 or 2 or 4 or 16 or 32 or 64). Tímto ukládáním se totiž rapidně sníží množství ukládaných dat.
    23.3.2012 10:36 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    K tomu by se lépe hodil bitový řetězec, ale nevím, jak jej PostgreSQL umí indexovat. Spíš bych ale použil normální spojení dvou tabulek. Nevím, co je to za mýtus o časově náročném spojování – to spojení žádnou zátěž nepřidá, podstatné je to hledání podle indexu. A tomu se stejně nevyhnete, naopak při použití 2 tabulek můžete použít standardní indexy a operace, na které je ta databáze už desítky let optimalizována.
    23.3.2012 11:19 kuka
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Tak spojeni velkych tabulek muze byt vypocetne velice narocne, to neni zadny mytus, zalezi na konkretni situaci. K optimalizacim je treba pristupovat vzdy s ohledem na ocekavane scenare. Jestlize napriklad tech stanic je 10 a ocekava se, ze dotaz tedy vybere zhruba desetinu zaznamu z tabulky, tak je prinos pristupu pres index sam o sobe diskutabilni a vetsina databazi rychleji provede full scan. Like bude typicky mnohem pomalejsi nez substr nebo bitova operace nad ciselnym priznakem, coz muze byt u velkych objemu take hodne videt. Neznam samozrejme konkretni scenar, ale obecne databaze byvaji dobre v praci s velkym poctem radku (a maji na to prostredky - partitiong, komprese...) a slabsi v nejake vnejsi logice (jako zde ten priznakovy retezec). Pomerne caste je ukladani aktualnich dat v neoptimalizovane "pruzne" strukture (napr. okamzite lze pridat dalsi stanici) a konsolidace starsich dat vice nebo mene "natvrdo" podle ruznych kriterii (uspora mista, rychlost konkretnich dotazu, moznost drilovani v EUL atd.)
    23.3.2012 12:01 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Tak spojeni velkych tabulek muze byt vypocetne velice narocne, to neni zadny mytus, zalezi na konkretni situaci.
    Je to mýtus. Spojení velkých tabulek nic nestojí. Nákladné je vyhledávání. Zkuste si to. Udělejte si SELECT na spojení tabulek, a pak soustavu SELECTů, která vybere ta samá data bez spojení v databázi (spojení uděláte v aplikaci). To druhé bude pomalejší – hledání použije stejné indexy, ale v druhém případě bude víc režie se spojením, parsováním dotazů apod.
    23.3.2012 14:43 kuka
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Databaze zvoli pro vyhodnoceni dotazu nejaky plan a podle nej potom postupuje - nacita data do pameti, provadi joiny, sorty, agregaci... Kazda z techto operaci ma svou cenu z hlediska spotreby pameti a vypocetniho casu. Jestlize je zvolenou operaci napr. hash join tabulek o radove milionech zaznamu, trva takova operace i na hodne nabusenem zeleze nekolik desitek vterin. Pokud mam data rovnou v jedne tabulce, je cena jejich "spojeni" nulova, je to treba jeden ze scenaru pouziti materializovanych views. O jakesi "aplikacni nahrade" nebylo reci, v aplikaci samozrejme nelze dosahnout vykonu, jaky ma pro tento typ operaci databaze, ktera je na to roky optimalizovana a ma k datum pristup na nizke urovni.
    23.3.2012 15:11 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Spojení se dělá vždy hledáním nějaké hodnoty. Přičemž když si to rozdělíte a podíváte se na ty náklady zvlášť, ono spojení má nulový náklad a hledání má nenulový náklad. Takže jestli přidáte to spojení nebo ho odeberete, nemá to na výkon vliv. Následující dva dotazy jsou pro databázi stejně náročné, přestože první používá spojení tabulek a druhý ne.
    SELECT A.*
    FROM
      table1 A
      JOIN table2 B ON (A.id = B.a_id)
    WHERE
      A.id = 1
    
    SELECT A.*
    FROM
      table1 A
    WHERE
      A.id = 1
    
    23.3.2012 15:39 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    K čemu tam to B je, být DBE, tak na celý JOIN kašlu, a rozdíl nákladů bude to kroucení hlavou nad B.
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    23.3.2012 15:42 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    No právě.
    23.3.2012 15:45 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Hledáte tedy prvotní příčinu zvýšení náročnosti?
    Tedy něco jako, že spojení tabulek nic nestojí, protože to co něco stojí, jsou ty operace nutné proto spojení? :-)
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    23.3.2012 16:16 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Ta operace nutná pro spojení je vyhledávání. A když tu operaci vyhledávání vyvolám jinak, než při spojování tabulek, bude stát úplně stejně.
    23.3.2012 15:51 kuka
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Ne ze by na tom z hlediska teto diskuse zalezelo (ucel toho prikladu nechapu), ale ty dotazy nejsou ekvivalentni a na tabulku B se vykaslat nelze.
    23.3.2012 15:55 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Hm, jo, to mi ujelo (ale třeba někdy jo :-))…
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    23.3.2012 15:47 kuka
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Striktne vzato nejsou stejne narocne, protoze v prvnim pripade se cte tabulka B (nebo jeji index), coz nema nulovou cenu. Nicmene bavit se o takovych prikladech nema v zasade smysl - samozrejme ze join jednoho zaznamu za pouziti indexu nema vysoke naroky na vykon. Neco jineho ovsem uz ovsem muze byt join vsech zaznamu mezi velkymi tabulkami. Nejde o to, jak se napise dotaz, ale jak se navrhne datovy model. Jestlize se napriklad rozhodnu pro nejakou formu redundance, mohu si joiny proste zcela usetrit. Pri analytickych dotazech se casto pracuje s velkym objemem dat, nezajima me napriklad jeden konkretni klient, ale top x klientu s nejvetsim objemem obchodu. V principu musim v takovem pripade projit vsechny zaznamy o obchodech a pokud je mam v nekolika tabulkach, tak tyto musim spojit a vysledek pak mohu agregovat. Pokud mam data v jedne tabulce, tak nic nespojuju a nektere dotazy jsou i radove rychlejsi. Samozrejme ne vsechny, pokud se ptam na jednoho konkretniho klienta, tak zadne meritelne zrychleni nepocitim a pritom mam starosti s udrzenim konzistence vzhledem k redundanci, data maji o neco vetsi fyzicky objem atd. Typicky se takto konsoliduji data, u kterych uz nedochazi ke zmenam a datovy model se dela na miru ocekavanym typum dotazu.
    23.3.2012 16:22 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Já už to asi jinak napsat nedokážu. Ta drahá operace je vyhledávání. V joinu je vždy skryté vyhledávání. Ale to spojení nepřidává žádné náklady navíc, nad to vyhledávání. Takže myslet si, že když místo spojení použiju vyhledávání, něco tím ušetřím, je to nesmysl. Můžu ušetřit tím, že jinak postavím dotaz, udělám jiné indexy, jinak rozvrhnu data. Ale pokud dva dotazy povedou na použití stejných indexů ve stejném pořadí a se stejnými daty, a v jednom případě půjde o spojení a v druhém o čisté hledání, nebude v tom z hlediska náročnosti operace žádný rozdíl, to spojení nepřidá žádnou složitost navíc k tomu vyhledávání.
    23.3.2012 16:39 kuka
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Ja vubec nechapu, co je podle tebe spojeni a co vyhledavani a proc na tom zalezi. Dotazem snad vzdycky neco hledam, proc bych ho jinak delal? Zda je k takovemu hledani treba join konkretnich tabulek zalezi na datovem modelu. Co rikam je, ze kdyz dam data do jedne tabulky, tak nemusim delat join. Kdyz je mam ve dvou, tak musim delat join (lepe receno databze ho musi udelat). Napriklad pokud mam v tabulce klient priznak, zda ma kreditku, a chci zjistit sumu operaci klientu bez kreditky, tak musim klienty spojit s operacemi, jinak nepoznam, zda mam danou operaci zapocitat. Pokud je klientu bez kreditky milion a operaci sto milionu, tak takove spojeni pobezi docela dlouho. Pokud budu mit priznak o kreditce rovnou v operacich, tak zadne spojeni neprovadim a rovnou agreguju v ramci fullscanu tabulky operaci (ktery musi probehnout v obou scenarich).
    23.3.2012 19:34 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Jenže tady řešíme jiný případ. Buď budu mít data ve dvou tabulkách a indexy, přes které je dokážu propojit. Nebo budu mít data v jedné tabulce a nad ní takový index/indexy, které budou to propojení dvou tabulek simulovat. Já tvrdím, že to spojení dvou tabulek nepřináší žádnou zátěž navíc a principiálně bude obojí stejně rychlé, protože se bude používat stejný typ indexů nad stejnými daty.
    23.3.2012 23:28 kuka
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    V mnou uvadenem prikladu se v zadne rozumne databazi indexy nebudou pri spojeni pouzivat, to by trvalo pul dne. Kdyz mam data v jedne tabulce, tak proc bych simuloval nejake spojeni, to je blabol. Evidentne neznas zakladni algoritmy pouzivane v databazovych strojich. Na tom neni nic spatneho a pro radu aplikaci transakcniho typu, jako jsou ruzne eshopy apod., to nemusi vubec vadit, take jsem to prilis neznal, dokud jsem to nezacal potrebovat. Ale nesir prosim bludy typu ze spojeni velkych tabulek nic nestoji.
    24.3.2012 09:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Proč se k tomu pořád vyjadřujete, když jste nepochopil, o čem se bavíme? Tak se prostě smiřte s tím, že to píšu nesrozumitelně a vám není dáno to z mého textu pochopit. Já jsem nikdy nenapsal, že spojení tabulek nic nestojí, takže celé vaše komentáře na tom postavené jsou k ničemu.
    okbob avatar 23.3.2012 20:24 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
    Pro časové řady jsou v PostgreSQL pole - pro každou stanici a hodinu můžete mít pole o 3600 prvcích a nemusíte provádět ručně takovéhle ošklivosti - když už používáte relační db, tak není ani praktické snažit se do db ukládat závislé magické konstanty - to už pak je lepší cpát data do souboru jelikož na takhle deformovaných datech se stejně dost špatně píší dotazy.

    Pole v PostgreSQL jsou docela vychytávka - navíc pro Vás transparentně se komprimuje obsah. A pokud nebudete extrémně často měnit konfiguraci, tak tím snížíte počet záznamů v tabulkách, cca o 3600/počet stanic - jestli jsem to pochopil, což při režii, kterou má pg, ke každému záznamu může být významná úspora.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.