Názor k článku
MySQL má nástupce InnoDB od Pavel Stěhule - Jak casteji? Ja mam vsude autovacuum. Problem s...

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(*).