Zpomalujici se Pg

[Jan Kasprzak]

Karel Zak wrote:
: > :  Mozna jeste -- proc jsi tam mel volani 'sync'? PostgreSQL zrovna na
: > :  fsync je celkem citlivy, a nejlepsi je kombinace UPS a zakazat volani
: > :  v nastaveni fsync po kazde transakci.
: > 
: > 	Sync/sleep tam bylo proto, aby to mereni bylo aspon trochu
: 
:  Jo, ale lezes mu do zeli, prave optimalnimu volani fsync je venovano
:  znacne usili.

	Ale houby :-) fsync() se vola nikoliv kvuli tomu, aby snad
DB stroj nejak optimalizoval zapisy na disk, ale jako bariera toho,
ze data pred volanim fsync() zapsana budou commitnuta na disk.
No a protoze s tou DB nic jineho nez toto mereni nedelam, muzu si dovolit
luxus zavolat sync() a zahrnout tak do mereni i pripadne zapisove operace,
ktere by sly na disk az treba s pristi transakci. Ale jak jsem rikal,
zapis na disk nebylo uzke misto.
: 
: > deterministicke. Zakazat fsync() po kazde transakci? A verit ze mi
: > system nespadne kvuli necemu jinemu? Ne, tohle budu delat az bude
: 
:  Je tam WAL log a ten (od verze 7.1) konzistenci garantuje. Ostatne
:  muzes zkusit poslat -9 :-)
: 
	OK, budu ti verit. Tohle ovsem uz vypada zajimaveji: Pokud si
ta databaze dela log vsech transakci, tak proc teda musi delat to, ze si
uchovava i stara data po updatovanych zaznamech? Pokud uz ma v logu celou
commitnutou transakci, tak by prece nic nemelo branit tomu, aby se ta
puvodni data prepsala, ne?

	Je nekde nejak rozumne (<5 stranek) popsano, jak vlastne Pg
implementuje transakce, co se deje se starymi daty, jak se pozna ktera
data uz jsou platna, co se deje s novymi daty dokud neni zapsana cela
transakce, atd?

	Da se ten WAL log pouzit pro replikaci a pripadne vytvoreni
(temer) hot standby databaze?

-Yenya

-- 
| 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  --|