postgres a lockovanie

[mIHAU]

Doufam ze posledni post na toto tema ode mne.

>	Pruser??? A v cem jako?
Mluvime o rychlosti nekterych operaci - predstavte si nutnost aktualizovat
DENNE z nekolika zdroju desetitisicove zaznamy - zpracovavat dbf sekvencnim
prochazenim a chytat zmeny do pgsql. Tady mi moc nejake sql operace nepomohou -
stejne se o logiku stara php skript a stejne to nejde udelat jinak nez pro
kazdy zaznam selectnout odpovidajici zaznam v pg a neco s nim provest pokud je
treba. Postgres mi to udela v tomto konkretnim pripade za 2.5 hodiny (a zatizi
mi system natolik, ze s tim strojem v te dobe moc neudelam) nebo za 1.5 pokud
vypnu flushovani po kazde transakci (coz se mi zase vymsti kdyz vypnou proud).
Mysql se pohybuje nekde pod pul hodiny az ctvrthodinou - kecal bych kdybych
tvrdil ze to vim presne - a nejsem si vedom, ze bych neco delal prilis spatne -
konzultoval jsem to pred casem na listu s Tomem Lanem.  Je to asi nekde jinde
nez se vy bezne pohybujete - netvrdim, ze je to standartni databazova aplikace
uzavrena do sebe, kde to asi vypada jinak.

   > >> Nebavme se o pouziti pg na nejakou aplikaci s 50 tabulkama atd.
Kde to na webu >> uvidite? Predstavte si treba obchod se sortem 100 000 titulu
- to udelate na 3-4 >
>	Ten shop bych chtel videt, resp. zpusob jakym jsou delany objednavky a
>co skutecne zaznamenavate, protoze IMHO se ritite do krasneho pruseru,
>ale to poznate az v nem budete...

www.tony.cz :) A objednavku
ukladam v ramci tabulky se session informacemi do pole.

Mozna JSEM mimo, ale ma logika se pohybuje nekde v teto rovine:
1. SQL MUSI FUNGOVAT 
2. POKUD BY nejaka query neprobehla, ze skriptu v php se mi posle varovny mail
se zaznamem problemu - stalo se to zatim dvakrat a v obou pripadech to bylo
'diky' providerovym zasahum na serveru - restartoval backend.

>	
>> soucasnych klientu na 75%... A take je pro vas podstatne, ze tabulky vam
>> zaberou s mysql mnohem mene prostoru, takze za hosting zaplatite mene.
>
>	Muzete rici trochu pomer nez takto hodit do placu..? Ano vim, ze
>postgres ma trosku rozezranejsi tabulky, ale kolik % je to skutecne v
>realite?

Ted bych strilel. Co si pamatuju, BYLO to znat. Nevim uz ale pomer. Urcite
neslo o nejakych 5-10 %, ale podstatne vice. Ale neda se rict prilis konkretni
cislo - neni to jen odlisnym formatem ulozeni zaznamu, ale predevsim
no-overwrite logikou - po mohutnejsich updatech je treba delat honem vacuum,
ale to zas musite shodit indexy (jinak to potrva 2 dny :)), udelat vacuum a zase
indexovat. A to chvili trva, takze v te dobe maji zakaznici smulu :(


--
Michal Samek, Tony distribuce s.r.o.
webmaster na tony.cz  (++420659/321350)
ICQ: 38607210