Zpomalujici se Pg

[Horak Daniel]

> 	mam takovy problem - tusim ze neco podobneho zminoval 
> Michal Krause,
> kdyz jsem se s nim bavil na Invexu. Jde o to, ze se postgres 
> postupne zpomaluje
> az do uplneho zpomaleni. Modelovy priklad:
> 
> Tabulka:
> create table sa_ping_kas (id int primary key, txt varchar(256));
> 
> Naplneni:
> insert into sa_ping_kas ($_, 'rand(999)')
> kde $_ je od 1 do 1000, rand(999) je realne cislo prevedene 
> na retezec.
> 
> V cyklu spoustim tento kod:
> 
> for my $run (1..1000) {
>         my $start = time;
>         for my $iter (1..100) {
>                 my $start = 1+ int(rand(980));
>                 my $text = rand(999);
>                 $dbh->do("update sa_ping_kas set txt = '$text' "
> 			. " where id >= $start and id <= ". 
> ($start + 19));
>         }
>         print time-$start, "\n";
>         system 'sync';
>         sleep 2;
> }
> 
> cili v podstate delam update nahodne vybranych 20 vedle sebe lezicich
> radku tak, ze menim hodnotu "txt" na neco jineho nez predtim.
> Kdyz tohle spustim, tak mi to vypisuje cisla okolo dvou sekund, ktera
> se postupne zvysuji (zatim po cca 60 iteracich jsem u 5 sekund).

Vychazi mi z toho, ze je provedeno 1200 updatu na tabulce s 1000 zaznamu
=> tabulka naroste na vice nez dvojnasobek. Duvod je uveden nize.

> Kdyz dam "vacuum sa_ping_kas", tak se to zase zrychli na 2 sekundy.

Po "vacuum" zustane zase jen 1000 zaznamu.

> 
> Podobny problem mam i u jine situace - tam mam tabulku s 
> primarnim klicem
> typu varchar(64) a snazim se delat
> 
> select primarni_klic from tabulka order by primarni_klic

jaky je EXPLAIN?

> 
> Tohle se taky cim dal vic zpomaluje s tim, jak do tabulky 
> delam updaty.
> A po vacuum se to vyrazne zrychli.

Tady je nejspis problem s tim, ze krome vlastni tabulky narusta i index.

> 
> 	Cili dotazy:
> 
> - Proc vacuum kdyz v tabulce nepridavam ani nerusim zaznamy?

Protoze PostgreSQL neprepisuje zaznamy, na kterych provadim UPDATE, ale
zaklada nove.

> - Jak muze byt pomale vyhledani podle primarniho klice, kdyz rozlozeni
> 	hodnot v tabulce je naprosto rovnomerne?
> - Proc se teda Pg nerozhodne cas od casu ten index prepocitat sam,
> 	kdyz uz je jasne, ze je nekde neco spatne.

> - Jak tenhle problem odstranit, pokud nechci periodicky po nekolika
> 	malo hodinach delat vacuum?

Napsat storage manager, ktery bude umet "neplatne" radky znovu pouzit -
urcite je to v TODO.


			Dan