ARCHIV

Zmínil bych zejména, že transakce představují prostředek, kterým jeden proces (spojení, sezení) skrývá dočasné změny před jinými transakcemi. Tedy další z podmínek ACIDu.

Zpomalování není obvykle výrazné, dnešní servery mají velmi účinné algoritmy na write-ahead logy a často používají multigenerační architekturu (Interbase/Firebird, Postgres tomu říká podivně - tuplevisibility :-). Zpomalení však bývá výraznější při paralelním zpracování transakcí, protože transakční plánovač musí volit správné pořadí a řešit uváznutí transakcí. A to není jen tak.

Transakce jsou v Postgresu velmi kvalitně zpracovány, je to velká deviza tohoto systému. Rychlost obnovení po pádu je díky této architektuře také skvělý. Na druhou stranu vzníká potřeba takzvaného "vakuování", kdy systém odstraňuje staré a neaktuální n-tice (tak bych asi překládal slovo tuple, vivat Python :-)

Pracoval jsem na projektu v MS SQL v tymu kde platilo pravidlo ze kazda operace se provadela pro jednu vetu (pry kvuli rychlosti). treba transakce delete ktera mela vymazat z dceriny tabulky se provadela ve smycce
np:
select top 1 @ida=ida from deleted d (nolock)
begin transaction
declare xxx cursor local fast_forward for
select xxx from xxx (nolock) where id=@ida
open xxx
fetch next from xxx into @idb
while @@fetch_status=0
begin
delete from rrr where idb=@idb
atd..
misto prikazu
delete from rrr ida=@ida
index byl vsude jak ida tak idb na dcerine tabulce
Je neco takoveho nutne i u PostgreSql ?

Ja bych se ptal, jestli je to opravdu nutne u toho MSSQL, tohle je dost divne a na vic temer spolehlive pomalejsi nez proste "delete from rrr where ida=1;".

Já bych - vzhledem k tomu, že MSSQL znám dost dobře - označil použití kurzoru pro mazání za dost velký úlet. Mohlo se použít cokoli jiného, plain příkaz, uložená procedura, referenční integrita atd. Ale sestavovat kurzor je opravdu velmi špatné řešení. U PostgreSQL to nutné není a nutné to není u žádné DBMS, kterou znám. Naco by pak prosté příkazy DELETE byly, když by se nedaly používat?

Treba by vysledna aplikace byla pri pouziti obycejneho delete tak rychla, ze by tam nemelo smysl davat progressbar, coz by pochopitelne snizilo jeji cenu :)))

Á, tak to jo. A taky půjde "optimalizovat na rychlost", pokud si to bude zákazník přát ;-)))))

Vysvetleno mi to bylo zpusobem ze system pri zpracovani delete,update,insert na vice vetach je o hodne pomalejsi kdyz zpracovava po jedne vete vicekrat. Taky mi pripada ze rezije nacti do cursoru a pak maz ve smycce musi byt velka ale sef na tom trval.

Toho šéfa bych vyměnil, vůbec neví, o čem je řeč. Například takový Ken Henderson říká "kurzory použít jen v nejnutnějším případě (třeba když na Vás někdo míří pistolí nebo když přijede tchýně)". Citace z "Mistrovství v Transact-SQL".

Kurzory svuj smysl maji, ale konkretne tohle pouziti je vylozene debilni. (teda ne ze bych nekde kurzory vyuzil, akle zrovna minuly tyden jsem rozumne vyuziti videl)