Dotaz: Jak to prepsat do mysql 5.0

[Radim Kolář]

db2 kod: SELECT ABALANCE INTO NEW_BALANCE FROM FINAL TABLE(UPDATE ACCOUNTS SET ABALANCE=ABALANCE+V_DELTA WHERE AID=V_AID)

pgsql kod: UPDATE ACCOUNTS SET ABALANCE=ABALANCE+V_DELTA WHERE AID=V_AID RETURNING ABALANCE INTO NEW_BALANCE

Jde o to zda se da jednim prikazem udelat UPDATE a ziskat aktualizovanou hodnotu sloupce.

---

---

Odpovědi

[Radim Kolář]

Update a select čistě jedním dotazem podle mého názoru v mysql nejde.

[Sten]

MySQL to neumí, ale lze to obejít přes proměnnou

[okbob]

To zdaleka není odpovídající - proměnnou můžete použít pouze v případě, že výsledkem je jedna hodnota.

[Radim Kolář]

Diky, ale uz to nepotrebuju. Delal jsem TPC-B benchmark a MySQL 5.0 byla suverene nejpomalejsi databaze a tak by nevyhrala ani kdyby se ubral jeden select. MySQL 5.1 v prubehu testu vzdy chcipla.

[okbob]

5.0 je stara jak metuzalem - buhuzel pro lidi, pouzivajici MySQL se vydavani releasu MySQL zadrhlo na 5.1 - vykonostne zajimava by mohla byt teprve pripravovana 5.6

[Radim Kolář]

jenomze mysql 5.1.50 je nestabilni a zamrzne v prubehu testu, takze moc navyber neni kdyz trvame na mysql.

5.0 je ovsem dobra parodie na rychlost. S vypnutym fsyncem u innodb je to jen 5x pomalejsi nez db2 s fsyncem a jen 1.5x pomalejsi nez oracle s fsyncem :) Presto je obcecne prijimano jako fakt ze mysql je nejrychlejsi database.

zajimavy je ze pgsql s vypnutym autovacuum je stejne rychly jako oracle prvni minutu ale bez vacuum jde vykon pak rychle dolu. Nakonec se ustali s autovacuum asi tak na 50% maxima, ktera ma v idealnich podminkach po vacuum full, coz se shoduje s mym pozorovanim produkcnich serveru. vacuum full je bohuzel tragicky pomaly na casto menenych velkych tabulkach (~20GB), nedobehne mi tam ani za 1 den. Ale ono to ve finale nevadi, vykon je i bez nej dostatecne dobry a diskspace levne.

Vacuum v 8.4 by melo byt lepsi, ale zase na tuhle verzi nikdo neprodava support, je moc nova. Testoval jsem 8.3.

Zajimavy je ze v tom testu s kterym machroval Lenin POWER! na root.cz ktery dela single row select z 20m tabulky opravdu vyjde db2 9.5 a pgsql 8.3 nastejno. V druhy casti testu kde se dela warehousing query vyjde db2 8x rychlejsi. Lepsi test by ale byl vzit $100k a postavit system na oracle a pgsql. U oraclu vam zbyde $20k na HW u pgsql vam zbyde na hw 5x tolik. V tomhle testu by uz pgsql mel bezproblemu zmastit oracle.

Stejne mne fascinuje ze tady v cechach je nejoblibenejsi databaze pro podnikove nasazeni mysql. To se ve svete fakt nevidi. Vetsina tech aplikaci co jsem videl nepouziva ani transakce a prodava se to za jednotky milionu. Proc si treba nekoupi Accpac coz vyjde vicemene na stejny penize ale dostanete krome lepsi aplikace (kvalita neni na urovni PHP student bastl) v cene i DB2 9.1.2 pro 4 CPU core, coz na 200 useru staci.

[okbob]

V 8.3 ma autovacuum jeste docela velkou rezii - coz se pak meni v 8.4 a zasadne v 9.0, kde je jak rychlejsi vacuum tak i full vacuum. Ale pokud je pro Vas 8.3 nova, tak na 9 se dostane tak v roce 2012 :).

Dost aplikaci tu vznikalo na kolene, a kdo tu rozumel databazim? Osobne jsem si myslel, ze nejcastejsi db je MSSQL a MySQL se pouziva jen na vedlejsi subsystemy. Duvod pro oblibenost MySQL je jednoduchy - cena a neznalost - pripadne neohodnoceni rizik.

Jinak 5.0 je snad jeste pomalejsi nez 4.x db. Tahle verze se opravdu moc nepovedla. I kdyz si vzpominam, jak jsem z ni byl u vytrzeni :). p.s. je to take o konfiguraci.

[Radim Kolář]

Dokazal by jste (presne receno protlacilo by se) do pgbench kompatibilita s TPC-B? Potreba dodelat ref. integritu, do tabulek a doplnit sloupec fill CHaracter(x) tak aby zaznamy byly 100 bajtu dlouhe s vyjimkou history ktere ma byt 50. a jeste (x)balance musi byt number(10). V dokumentaci k tpc-b se nepise jestli tech 100 bajtu musi byt logickych nebo na disku, ja se priklonil k druhe variante.

mne ta delka sloupce fill vychazi

int fillsizes[] = { 59, 55, 55, 1 }; pro branches,tellers,accounts,history.

[okbob]

Asi by to slo - ted nevidim duvod, co by proti tomu mohl nekdo namitat. Postup je docela jednoduchy - prihlasit se do konference pg_hackers - poslat tam mails se subjectem PROPOSAL: ... a nastinit smysl zmeny a implementacni detaily - a pockat na reakci.

[Radim Kolář]

kdyz se podivate do zdrojaku radky 1225 tak vidite ze nemaji zajem na TPC-B kompatibilite.

http://doxygen.postgresql.org/pgbench_8c-source.html

V zasade je potreba jen upravit data typy, generovani delta a dodrzovat delku radek. Mozna dodelat TPC-B kompatibilni rezim, kdyz to ma uz -N a -S.

[okbob]

Ten komentar bych zas az tak nebral vazne - minimalne nyni doslo ke zmene z duvodu podpory vlaken - navic, kdyz se podivate do historie, tak k takovym zmenam doslo behem poslednich let nekolikrat - jde spis o to, jak se to poda, a kdy se to nadnese - neco, co jeden rok je bez sance je za rok vrele privitano. Nicmene je dobre vzdy nabidnout zadni vratka - kompatibini rezim nebo specialni rezim.