Názory k článku
MySQL má nástupce InnoDB

Není nad to, co si člověk vyzkouší sám - zvláště v oblasti open software se schopnosti sw dost fanaticky nadsazují. Ničemu jinému se příliš nedá věřit.

Jinak máte opravdu pocit, že neustálé resetování systému je klasický stav databází v bankách? Zkuste naběhnout do bankovního domu, nebo do nějaké nadnárodní firmy a nabídněte jim, že jim jejich důležitá data bude spravovat nad Firefoxem, neřku-li MySQL. Možná jim to bude připadat jako dobrý vtip, budou-li v dobrém rozmaru. Ono totiž u db je důležité více věcí, než pár papírových parametrů, nebo rychlost.

Celé je to o tom, že je sice hezké, že nějaký Falcon a další mají skvělé vlastnosti (i když vlastně ani ještě pořádně neexistují, ale to tu nikomu nebrání kecat a prášit se mu od úst, jak jsou skvělé, proč taky taková drobnost). Právě na razanci a intenzitě obhajoby ještě neexistujících věcí a jejich vyzdvihováním jak jsou dobré je krásně vidět nesoudnost jejich zastánců. Až budou, pak si povíme - a jak to v praxi bývá, parametry Falconu budou na 99,999% mnohem výrazně slabší oproti nadšení jejich propagátorů - pokud vůbec nějaký Falcon se kdy dočká release verze, protože ani to není jisté.

I něco takového se ke mně doneslo. :-) O bankách bych pomlčel, jeden známý se zařekl, že bance, pro kterou programuje, už v životě peníze nesvěří. V tomhle případě ale armáda prostě zadala výběrové řízení a jediný SW, který vyhověl, byla Starkeyho Interbase. :-) Firefox bankám vnucovat nebudu, jeho databáze je poněkud slabá :-) (naposledy měl rozhraní pro sqlite).

Já si o pozadí bank také myslím leccos, ale zkrátka db, kterou vážně nasadíte musí být db, za kterou někdo stojí, někdo jí servisuje, a někdo na ní dává nějaké záruky, tj. že bude podporována ještě za x let a spoustu jiných záruk a to řadu let dopředu. Kromě toho to musí být prověřená db a musí mít i seriózní, vybudovanou značku. Nic z toho u Interbase/Firefoxu nemáte. Já osobně, kdybych se rozhodoval, tak se rozhoduji podobně. Db bez záruk o budoucnosti a o servise - ta prostě do ostrého nasazení na místa, kde na načem skutečně záleží zkrátka nepatří, i kdyby byla pozlacená, nejlepší a nejskvělejší.

Ohledně resetování - běžná db snese tvrdý reset a je dělaná na to, že občasné sletění systému na ústa zvládne. Nicméně počítá se s tím, že to nebude obvyklý stav věci.

Komolení jména Firebirdu je opravdu dětinské. Profesionál který si je jist svými argumenty se k takovým věcem uchylovat nepotřebuje. Že by jste síle svých argumentů zase tak moc nevěřil?

Jestli je to jediný argument, který jste schopen vznést, pak je mi Vás líto. Chápu, že pro Vás, jakožto pro člověka je název db, který Vás živí něco co nespletete ani když Vás vzbudí o půlnoci. Vzhledem k tomu, že člověk běžně pracuje se stovkami názvů produktů je občasné zmýlení se v názvu celkem pochopitelné. Jinak snadno dohledáte, že zesměšňování názvů produktů není mým stylem.

Mé jméno i příjmení je komoleno prakticky několikrát denně (neboť jméno je nezvyklé a příjmení se velmi podobá jedné pražské čtvrti) a problém z toho nedělám. Je totiž velký rozdíl mezi komolit a zesměšňovat. Komolení jméno mého zaměstnavatele, nebo produktu ve kterém dělám mi nevadí už vůbec - dokážu pochopit, že není v lidských silách si zapamatovat vše, co je na reklamních plakátech. Nehledě na to, že 99% jmen produktů má jepičí život. Takže pokud budete komolit mé jméno v dobré víře, že ho říkáte správně, není proč vyvolávat války, hádky atd.. Dokážu vycítit proč člověk komolí mé jméno a pokud to není úmyslné, opravdu mi to ani v nejmenším vadit nebude.

Pokud zkomolím jméno člověka, okamžitě se omlouvám. Je to ryze osobní záležitost.

Co se týká jmen produktu, opravdu není v lidských silách vše pobrat. A to nemluvím o fanaticích, kteří Linux fanaticky opravují na GNU/Linux, OpenOffice na OpenOffice.org atd.. To opravdu podporovat nechci a nehodlám.

Stačí si přečíst Váš příspěvek a je naprostojasné, že jste ztratil soudnost. Že z Vás čiší snaha mě poškodit, a že Firebird je pro Vás jenom záminka, která Vám má pomoci, ale ve skutečnosti tu o to nejde. Na jedné straně se ptáte, jestli by mi vadilo, kdyby mě někdo komolil jméno, teď píšete že moje jméno nikoho nezajímá. Prostě kdo chce psa bít, hůl si vždycky najde - Vám nejde vůbec o zkomolení jména Firebirdu, Vám jde jen o to, že nezvládáte svojí nenávist.

Já jen doufám, že až Vy jednou zkomolíte nějaký pojem v dobré víře, že budete k sobě stejně přísný jako teď prezentujete a necháte se pro výstrahu zastřelit, protože žádný menší trest za komolení jména samozřejmě nemůžete přijmout.

Hm, začínáte být čím dál více nesoudný, a Vaši agresivitu, nenávist a další už ani neskrýváte. Podle sebe soudím Tebe - vše co mi přisuzujete jsou Vaše vlasnosti. Prostě mě chcete setřít, tak do toho. Toto je totiž moje poslední reakce na Vás - plně se rozepište o mých nejhorších vlastnotech, pořádně mi to nandejte, a využijte toho. Já totiž Vaše reakce nechám zcela bez odezvy, takže se snažte.

Vidím, že moje osoba Vás zaujala. Samozřejmě mým fanouškům nehodlám nijak bránit a naopak jim pomáhám co můžu. Stačí napsat mail a klidně se Vám i podepíšu do deníčku. :-) Jinak tady jsme na internetu pane, nehodlám nic potvrzovat, ani vyvracet.

Jo, s Falconem Vám neporadím, nevím, co tam vařej, a jak dlouho jim to může trvat. Ale Vulcan si zkuste, až vyjde beta, třeba se Vám bude líbit. Kód je v podstatě hotový, problém je integrace do Firebirdu, protože Borland zku*il, zprasil atd. co mohl, a vývojáři přiznávají, že místo, do kterého se musí ten engine ve Firebirdu naroubovat, je hrozná změť. Takže to může chvilku trvat, prý mohou být tři integrační vlny, s meziverzí 2.5. Do té doby to budeme muset vydržet, Vy samozřejmě můžete dál křepčit nad Oraclem, který já si ho jako člověk s potřebou malých a nepřekážejících embedded vecí instalovat nebudu. ;-)

Já nepotřebuji radit s Falconem - ale všimněte si, jak tu spousta lidí uvádí jeho vlastnosti, včetně toho, že Oracle se potom půjde zahrabat. Buď jsoum totálně zhulení, nebo opilí až namol, nebo dokonale nesoudní. Stačí se podívat do historie na bombastické uvádění různých vaporware, či na to, jak přehnané příznivé vlastnosti jsou dávány všemu co se plánuje a jak se schlípýma ušima se pak dívají manažeři, či technici na tu hrůzu, až to naplánované vznikne. Takže oslavování Falcona je hovadina - až tu bude povíme si (pokud vůbec někdy bude), dokud ne - byl bych při zemi.

Kód je v podstatě hotový, problém je integrace do Firebirdu, protože Borland zku*il, zprasil atd. co mohl, a vývojáři přiznávají, že místo, do kterého se musí ten engine ve Firebirdu naroubovat, je hrozná změť.

Ideální případ - vývojáři to prostě mají na koho svést, jsou z obliga. A Borlandu se nic nestane, když se na něj snese nějaká ta špína a vývojářům to pomůže, tak co.

Každý program má takovou architekturu, se kterou počítá při návrhu - pokud si vymyslím něco neobvyklého (platí pro jakýkoli sw i ten nejčistější a nejlépe navržený), na který původní architektura programu nebyla připravena, pak samozřejmě dojde k podstatnému přepisu. Házet ovšem ještě navíc špínu na hlavu Borlandu, tím se u mě vývojáři Firefoxu hodně shodili. Protože to je stejné, jako skočit z okna a nadávat, že jsem si zlomil nohu.

Vážený pane, mohu vás ujistit že řada bank a nadnárodních firem svá důležitá data ve Firebirdu spravuje. Bohužel nemohu příliš hýřit jmény, protože bez jejich souhlasu o interních operacích našich zákazníků mluvit nelze. Nicméně o takovém MICEX (Moscow Currency Exchange) se to obecně ví (Firebird na HP-UX je už mnoho let v centru veškeré výměny peněz mezi Ruskými bankami). Řada Fortune 500 firem využívajících služeb SAS Institute vlastně také používá Firebird (jádrem nové platformy je Vulcan, v budoucnu pak Firebird 3). A to nemluvím o bezpočtu nasazení Firebird embedded v klientských a mobilních aplikacích (ten používají nejen banky, ale i např. takový německý T-Mobil). A to jsou jen klíčové aplikace u velkých firem, nasazení v podpůrných projektech a department-level aplikacích je nepočítaně. Nicméně finanční ústavy a nadnárodní firmy nejsou nijak zvláštní zákazníci, protože i pro menší firmy a instituce jsou jejich data významná. Co třeba takové nemocnice, že? Firebird jich používá docela dost.

Ano, řada důležitých dat se spravuje ve Firebirdu, akorát se nesmí říkat kdo. Skvělé a naprosto přesvědčující.

Velmi pochybuji, že hlavní databáze a hlavní data budou u banky, nebo nadnárodním koncernu ve Firebirdu. Že se pár nezodpovědných ústavů najde, o tom vůbec nepochybuji , ostatně stejně tak jako jsou zodpovědné firmy vážících si svých dat a nezodpovědné, které na to kašlou je zcela normální.

V mobilních aplikacích je samozřejmě Firebird zcela na místě, protože tam jen málokdy jde o klíčová data, jejichž ztráta by byla nenahraditelná. Zajisté se shodneme, že mluvit o Oracle, nebo DB2 v mobilech jaksi nesvědčí o zdravém rozumu. V podpůrných projektech a podobně není až tak kritické, co se tam nasadí.

Ohledně nemocnic vím dost a řeknu to tak, že bych brečel. Nejenom ohledně sw zázemí a dalšího, ale i ohledně dalších procesů, různých vyvedených penězotoků...

Ano, řada důležitých dat se spravuje ve Firebirdu, akorát se nesmí říkat kdo. Skvělé a naprosto přesvědčující.

V obchodní praxi je zcela běžné, že neveřejné informace o svých zákaznících nesdělujete bez jejich souhlasu. Nedělá to ani Oracle, IBM nebo Microsoft. Bohužel jste se ptal po existenci uživatelů Firebirdu, kteří zrovna spadají do kategorie obzvláště paranoidních pokud se zveřejňování informací týče, takže je mi opravdu líto, ale bez jejich souhlasu si je nedovolím ani jmenovat. Že vám mé slovo nestačí, je politováníhodné. Nicméně známých významných uživatelů Firebirdu je hodně, a některé z nich jsem vám vypsal již při jiné příležitosti (snadno si je v případě zájmu dohledáte).

Velmi pochybuji, že hlavní databáze a hlavní data budou u banky, nebo nadnárodním koncernu ve Firebirdu.

Skutečně velké společnosti nemají "hlavní data" (u společností tohoto typu je těžké vůbec určit, která data *nejsou* hlavní) v jediné databázi, ale jedná se o poměrně komplexní provázaný systém HW, databází a aplikací, a málokterá společnost má "hlavní" data spravovaná v jediném typu databázovém systému (např. Oracle nebo Firebird). Firebird se v takovýchto institucích používá, ale typicky to není jediný databázový systém, který používají, stejně jako nepoužívají jen Oracle nebo něco jiného.

Že se pár nezodpovědných ústavů najde, o tom vůbec nepochybuji , ostatně stejně tak jako jsou zodpovědné firmy vážících si svých dat a nezodpovědné, které na to kašlou je zcela normální.

Je opravdu ostudné, jak jsou tyto firmy nezodpovědné. Svěřit svá data Vulcanu je přeci nesmysl!

Pane Císaři, nechme toho. Vraťme to na začátek - já jsem tu psal svoje názory na db, o Firebirdu jsem se zmínil jen okrajově. Je mi jasné, když to řeknu natvrdo a upřímně - Vy jste z Firebirdu živ - a je celkem očekávatelné, že chválou Firebirdu zaplníte každý patník, neboť jsou to penízky pro Vás.

Všimněte si, že násilně protlačujete Firebird, kde se dá. Mě jste dokonce napadl za to, že jsem zkomolil jméno Firebirdu, což je sice pravda, nicméně pokud z kontextu bylo jasně vidět, že to nebyl záměr, nýbrž překlep.

Vaše slovo mi nestačí, protože - nezlobte se, myslím to v dobrém - nejste v otázkách Firebirdu nestranná osoba. Jste s ním finančně i jinak svázán, a je ve Vašem vlastním zájmu, aby Firebird byl protlačován všude, i když by se tam třeba hodila lépe jiná db. Stejně tak, jako Billu Gatesovi a Steve Ballmerovi nebudu věřit vše co říká o Windows - protože má ohledně Windows své finanční zájmy, stejně tak nemohu od Vás bezduše a bez důkazů přebírat Vámi řečené o Firebirdu. Vaše slovo mi bude stačit v jakémkoli jiném případě.

Kdybych navázal na zbytek - vzhledem k tomu jak sám tvrdíte, že velké společnosti tají podrobnosti o svých databázích a Vy víte o té Firebird části (a pravděpodobně ani Vám nesdělili podrobnosti o své datové strategii), pravdu se stejně nedozvíme a tím bych zbytek textu považoval za irelevantní.

Aby bylo jasné, nepovažuji FB za špatnou databázi a myslím, že moje výhrady znáte a koneckonců jsem je sem také napsal. A teď o čem tu píšu - jen o tom, jaké věci považuji u db za důležité, přičemž o Firebirdu tu dokonce ani není hlavní řeč, ta je o MySQL. Protože právě teď celý svět sleduje co se bude dít s MySQL, neboť v poslední době se kolem MySQL událo dost zajímavých událostí : koupě InnoDb Oraclem, koupě firmy Sunem, vývoj Marii a Falconu a je zajímavé si zavěštit a zahrát na proroka.

Vraťme to na začátek - já jsem tu psal svoje názory na db, o Firebirdu jsem se zmínil jen okrajově. Je mi jasné, když to řeknu natvrdo a upřímně - Vy jste z Firebirdu živ - a je celkem očekávatelné, že chválou Firebirdu zaplníte každý patník, neboť jsou to penízky pro Vás.

Poněkud si pletete dojmy s pojmy. Vy jste se ptal na uživatele, a já odpovídal, což je na hony vzdáleno jakémukoliv vychvalování (a navíc o vlastnostech Firebirdu nepadla ani zmínka).

Vaše slovo mi nestačí, protože - nezlobte se, myslím to v dobrém - nejste v otázkách Firebirdu nestranná osoba. Jste s ním finančně i jinak svázán, a je ve Vašem vlastním zájmu, aby Firebird byl protlačován všude, i když by se tam třeba hodila lépe jiná db.

To bych chápal v případě, že by byla řeč o vlastnostech nebo schopnostech Firebirdu. Tady byla ovšem řeč o zákaznících naší společnosti, a vy zpochybňujete mé slovo, že mezi našimi klienty jsou i známé finanční ústavy a státní instituce.

Očividně si pletete Firebird a IBPhoenix. I kdyby všichni nakrásno používali Firebird, tak to vůbec neznamená, že z toho budu mít byť jen pětník. Firebird je zdarma pro každého, a opravdu z něho nemám ani korunu (naopak mě stojí čas a peníze). Obživu mám teprve ze společností, které se rozhodnou využít našich služeb. V podstatě si na chleba vydělávám jen díky některým (protože zdaleka ne všem) velkým a bohatým uživatelům Firebirdu, o jejichž existenci pochybujete. Navíc již řadu let je uživatelů Firebirdu několikařádově více než by byla naše společnost v současnosti schopna obsloužit kdyby se byť jen setina z nich dožadovala našich služeb, takže z čistě obchodního hlediska mi vskutku nesejde na tom, zda bude Firebird používat někdo další či nikoliv.

A teď o čem tu píšu - jen o tom, jaké věci považuji u db za důležité, přičemž o Firebirdu tu dokonce ani není hlavní řeč, ta je o MySQL. Protože právě teď celý svět sleduje co se bude dít s MySQL, neboť v poslední době se kolem MySQL událo dost zajímavých událostí : koupě InnoDb Oraclem, koupě firmy Sunem, vývoj Marii a Falconu a je zajímavé si zavěštit a zahrát na proroka.

Bohužel jste příliš nevěštil, pouze projevoval pochybnosti. Pokud chcete nějakou věštbu, pak tady jednu máte: Díky koupi Sunem jsou teď kluci z MySQL AB za vodou, a mají z krku trable s IPO a netrpělivými VC investory. Nemusí teď moc spěchat a mohou si vymýšlet blbosti typu Maria. Každý případný neúspěch se teď dá svalit na špatné zacházení a nepochopení ze strany Sunu. Sun využije MySQL aby prodal více železa jistým společnostem, a hlavně ji využije jako argument při manévrování s komunitou a některými partnery i protivníky. Ale jinak se nic zásadního dít nebude. Maria bude v konečném důsledku jen plácnutí do vody bez zásadního úspěchu, protože Monty je prostě Monty, a nic lepšího od něj čekat nelze. Falcon se bude ladit tak dlouho, dokud to bude Jima bavit. Pak Jim uteče za zajímavějším projektem (v rámci Sunu nebo úplně jinam), nejspíš ještě před naprostým dokončením. Existence MySQL v rámci Sunu bude plná pouze velkých PR kroků bez zásadního posunu kamkoliv (jinak řečeno bude mnoho povyku pro nic), vše se bude pouze více a více komplikovat. Díky technické roztříštěnosti a licenčním komplikacím budou Open Source projekty méně a méně využívat primárně MySQL, a zaměří se na podporu jiných databází, a v rámci LAMP stacku bude MySQL v průběhu následujících tří let postupně nahrazována jinými databázemi. Do pěti let bude MySQL de facto jen další databází, o které se nebude nebo možná bude mluvit tolik jako dnes (ale v jiných souvislostech).

1. Představa že Rusové jsou socky je opravdu úsměvná. Lidé jsou možná vesměs chudí, ale mnoho organizací je bohatších než průměrný stát třetího světa (obzvláště mají-li co do činění s peněžnictvím nebo nerostným bohatstvím). Pro MICEX nebyl a není problém zaplatit za cokoliv.

2. MICEX původně používal InterBase 3 pro HP-UX, která samozřejmě nebyla zadarmo. Bohužel Borland přestal InterBase pro HP-UX podporovat, takže pokud chtěli novější a udržovanou databázi, museli přejít na Firebird. Pokud vím, jsou velmi spokojení.

Že toho nějaký produkt umí víc ještě neznamená, že je pro danou úlohu lepší. Rovněž mě fascinuje vaše schopnost šmahem rozpoznat motivace a ohodnotit rozhodovací schopnosti jiných bez nejmenší znalosti situace. Chápu, že asi máte špatnou zkušenost, ale automaticky přisuzovat vlastní omyly jiným je krátkozraké.

Souhlasím s Vámi, že spousta aplikací je špatně napsaných. Je to prostě pokrokem, před určitým časem programátor, nebo databázista musel být člověk s hlubokými znalostmi, dneska je programátor kdekdo, kdo zvládne naklikat pár formulářů a když do toho zvládne udělat i menu, pak je senior programátor. Prosím, teď ani trochu nenadsazuji, ale popisuji reálný stav. U databázistů profesionálů už se také nedivím naprosto ničemu. Zkrátka neviditelná ruka trhu má více ekonomické působení, než aby to bylo o kvalitě.

Jinak žádná z přetřásaných db opravdu žádná sračka není, i když o MySQL už si to začínám pomalu myslet. Počet chyb, které u MySQL nalézám roste a zatímco dříve se dalo na MySQL spolehnout, dnes už běžně dost chybuje. A nespolehlivá db je o ničem.

To machrování je všude - takové rozšířené typy machrování skupin lidí, kterým narůstá nosánek hodně nahoru je - "já jsem Javista, ostatní jsou podlidi", pak dlouho dlouho nic, pak mnohem slabší machrování typu "cokoli kromě Oracle je sračka", nebo "cokoli co není GPL je špatné a je třeba to násilím převést na GPL".

Jinak abych řekl pravdu, mě chybí spíše malá až střední db, kterou bych mohl používat bundlovanou s aplikací. Nejnadějnější kandidát pro mě je sqlite. Firefox používat pro tyto účely nechci díky tragickému stavu dokumentace - takže černou skříňku používat nechci. MySQL nechci kvůli licenci, vychází dosti draho a také proto, že jsou její vlastnosti nejisté.

Víte přátelé, sedím v bance už nějaký čas a můžu vám říci, že to co se prezentuje od mnohých subdodavatelů je tragedie.

Nesedím v bance, ale naprosto souhlasím.

dvouletý vývoj pod RUPem

Mnoho lidí si myslí, že použijí RUP a bude všechno skvělé. Ale to je běžný stav - mnoho firem po nasazení ISO 9001 šlo do háje s kvalitou, protože kvalitu jim přeci hlídá to ISO.

Takže lidově řečeno - ona i blbá foxka může být rychlejší.

Přesně tak. Ono totiž záleží na celém vyvážení všech součástí řetězce. Jenže v poslední době se tu pořád melou jména technologií, a houby z toho.

Takže opět - ne-li něco začneme tvrdit, tak si uvědomme, o čem to vlastně je. O stabilitě, výkonu a odpovědnosti.

Naprosto to tak je.

Ale jinak mám raději sw, který je třeba horší, pomalejší - ale je na něho spolehnutí, má dobrou dokumentaci a to co deklaruje, taky bez problémů a bez řečí provádí. Bombastické řeči a efekty už ve mě vyvolávají varovné světélko. Nedělám sice momentálně pro banky, ale on spolehlivý sw je taky o tom, že něco udělám a můžu jít s někým na večeři, nebo někam. A nemusím trávit čas tím, že hledám, kde se zase sw podělal a dělat betatestera, nebo trávit čas tím, že se snažím zjistit informace, které by normálně byly v základní dokumentaci.

Každý sw, který rutinně a dlouhodobě chci používat si sám testnu (případně si předávám zkušenosti s pragmatickými lidmi podobného ražení) - a mám dost dlouhou praxi abych věděl, kam šťournout. Pak se taky dívám na to, jak dobrá je dokumentace (bez dobré dokumentace do toho vůbec nejdu - viz Firefox), jak je sw spolehlivý, jaká je šance, že tu ještě bude za pár let, jaká je architektura programu (hodně napoví o spolehlivosti i o mnoha dalších věcech). Hodně důležitá věc, skoro klíčová je licence sw - k čemu je učit se třeba GPL knihovnu, když vím, že ze mě GPL kód nepadá a padat nebude (padá ze mě public domain, BSD, nebo komerční)?

Pokud pak takový sw používám, pak klidně k němu přispěju, buď si ho zaplatím, nebo klidně napíšu, nebo opravím část kódu.

K Firebirdu je dokumentace špičková, jen není zadarmo. Bezplatně dostupná dokumentace sice není učesaná a sjednocená do jedné-dvou knih, ale *je* kompletní.

PostgreSQL se používá i na Slovensku - spíš bych to tipoval na problém mezí židlí a klávesnicí :) - obyčejně to jsou ty chyby, kdy celý večer marně hledáte chybu nebo řešení - a v okamžiku, kdy máte za zády kámoše, kterému se svěřujete s problémem, tak naprosto jasně uvidíte v čem je problém. Malá poznámka: kódování databáze je jedna věc a locales a jeho kódování věc druhá. Locales se nastavuje pro celý cluster ve chvíli, kdy se inicializuje. Až 8.3 kontroluje shodu kódování locales a databáze. Takže pokud budete mít cluster inicializovaný s cs_CZ.Latin2, tak v UTF8 databázích, které bezproblémově vytvoříte, budete mít problém s diakritikou - dá li P.B, tak 8.4 by mohla mít nastavení locales na databázi - toto hloupé omezení pochází z dob, kdy inicializace nebo přepnutí locales bylo pomalé - to již neplatí.

p.s. schválně si to zkuste, kde budete moci (v případě problémů jsem na ICQ, které jednoduše vygooglujete).

Jak casteji? Ja mam vsude autovacuum. Problem s mrtvymi zaznamy nemam, mne jen databaze dost rychle narusta.

Pak Vás ani nemůže limitovat max_fsm_pages. Ve starších verzích nízká hodnota max_fsm_pages zabránila dokončení vacua - což byl problém - muselo se spustit FULL VACUUM. Pokud máte pocit, že problém je v max_fsm_pages pak tuto hodnotu zvedněte nebo zvedněte četnost VACUUM. A nebo je někde jiný problém, který nedokáži od stolu ani odhadnout.

Maji ostatni databaze neco jako staticka velikost max_fsm_pages? DB2 ne, Oracle9 taky ne. To da taky rozum, proc nastavovat nejaky konfiguracni parametr podle predpokladane velikosti db, ktery naviz zpusobuje problemy kdyz se podhodnoti.

Jiné databáze buďto vůbec nepoužívají MVCC nebo používají jinou variantu - u Oracle se například musel nastavovat rollback segment. Optimální hodnota max_fsm_pages souvisí s velikostí tabulky jen okrajově - důležitá je četnost operace vacuum a počet UPDATE a DELETE operací.

Nikdo vas nenuti tu bitmapu ukladat do pameti, ukladejte si ji na disk jako ostatni.

Ona je uložené také na disku, ale pouze v paměti je k ni dostatečně rychlý přístup. Hlavně ostatní databáze nemají VACUUM. Neni to uplne top tema. S max_fsm_byl problem, dokud prilis nizka hodnota blokovala VACUUM. Ted se spis aktualne resi, jak uplne odbourat VACUUM a nebo jej co mozna nejvice eliminovat - napr. HOT. Dost by mely zmenit tzv. visibility maps, ktere do jiste miry prebiraji funkci fsm a navic pomahaji v urychleni VACUUM a COUNT(*).