Zpomalujici se Pg
Karel Zak
zakkr na zf.jcu.cz
Pondělí Listopad 4 12:04:17 CET 2002
On Mon, Nov 04, 2002 at 11:30:31AM +0100, Michal Krause wrote:
> On 01/11/2002, Horak Daniel wrote:
>
> Predne potvrzuji Yenyovu zkusenost (i fakt, ze jsem to probiral s Karlem
> Zakem :))
>
> > > Ono ve skutecnosti nejde ani tak o to, ze tabulka narusta
> > > (co uz, zejo). Jde o to, ze ten _index_ nejak nefunguje, resp. asi
> >
> > A opravdu se pouziva index? Co rika EXPLAIN pred updaty, po updatech,
> > po vacuum?
>
> Index se dle EXPLAINu opravdu pouziva. Coz je to, co me puvodne nejvice
> prekvapilo. Chapu, ze Pg nechava lezet puvodni verze updatovanych zaznamu,
> ono to asi neni v transakcnim prostredi jednoduche a tohle bude zrejme
> cesta nejmensiho odporu, ale neni mi jasne, proc to musi vest ke
Ne cesta nejmensiho odporu, ale nutnost -- tedy presneji dan za
pruchodnost sytemu pri cteni vice konkurujicich si transakci najednou.
> zpomaleni. Pri sekvencnim cteni a nekolika desitkach tisic zaznamu bych
> to pochopil, ale takhle me to trochu mate.
Pokud je jich 1000 a na kazdy 100x posles UPDATE tak jich je 100000 a
DB minimalne musi pres ty zaznamy seekovat.
Koukni na: http://www.dbsvet.cz/technologie/tc011102021101.html
Co ta rychlost udela pokud pouzijete VACUUM (bez FULL)?
Karel
PS. z toho by se dal udelat pekny clanek (mozna se na to podivam,
samotneho me tam par veci zajima:-)
--
Karel Zak <zakkr na zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Další informace o konferenci Test