Zpomalujici se Pg

[Jan Kasprzak]

Karel Zak wrote:
: 
: > 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.
: 
	Karle, jak uz jsem rikal: uzke misto _neni_ v seekovani. Ostatne
ta tabulka se 100000 zaznamy ma nejakych par megabajtu, cili klidne muze byt
cela v RAM. Navic top mi ukazuje ze prislusny "postmaster" zere 100% CPU,
a to temer vse jako user time, nikoliv system. Opravdu problem _neni_
v seekovani ale v tom, ze Postmaster "cosi" pocita. Porad mi prijde ze
update 20 zaznamu (cili v podstate pridani 20 zaznamu do tabulky a oznaceni
jinych 20 jako smazane) to cele 100x zopakovane nemuze trvat 80+ sekund,
kdyz s cistou tabulkou to trva pod dve sekundy.

:  Koukni na: http://www.dbsvet.cz/technologie/tc011102021101.html
:  
:  Co ta rychlost udela pokud pouzijete VACUUM (bez FULL)?

	Jak uz jsem psal, VACUUM bez FULL tomu pomuze, cas spadne zpet
na dve sekundy.

-Y.
-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
|-- If you start doing things because you hate others and want to screw  --|
|-- them over the end result is bad.   --Linus Torvalds to the BBC News  --|