Ahoj, pouzivam FB docela dost a s jeho optimalizatorem obvykle souhlasim, proto me docela zaujala tato veta "(a až na Firebird 1.5 samozřejmě i ostatní db systémy)" tim chcete rict ze FB optimalizuje hur ??
Tom
Názory k článku
Čtení prováděcích plánů v PostgreSQL
aura:90
1. 9. 2008 12:48
Nový
Re: Proc FB 1.5 samozrejme ne ??
celé vlákno
Ano, to chci říci. Optimalizace v 1.5 měla několik hluchých míst - jedním z nich bylo i nevhodné použítí unique indexu na malých tabulkách, což snad řešil optimalizér 2.0.
Randolf (neregistrovaný)
1. 9. 2008 12:14
Nový
Skvele!
celé vlákno
Jeden z nejlepsich clanku na rootu, dle meho nazoru. Za celou jeho existenci.
aura:100
1. 9. 2008 12:25
Nový
Firebird 1.5?
celé vlákno
Opravdu by mě zajímalo, kde jste přišel k informaci že Firebird (a navíc jen ve verzi 1.5) nezohledňuje při výběru prováděcího plánu náklady na zpracování indexů.
aura:90
1. 9. 2008 12:53
Nový
Re: Firebird 1.5?
celé vlákno
Je to už doba, ale vybavuji si dotazy ve Firebird konferencích ohledně blokování index. scanu na malých taulkách.
aura:100
1. 9. 2008 13:32
Nový
Re: Firebird 1.5?
celé vlákno
Škoda že si nevybavujete spíše ty odpovědi :-)
Firebird samozřejmě vždy zohledňoval náklady na zpracování indexu. Ono by to bylo dost divné zohledňovat náklady na čtení dat ale už ne indexů, a takového opomenutí by si za těch více než 20 let jistě někdo z vývojářů všiml :-) Pravdou ovšem je, že Firebird zdědil poměrně hrubý vzorec na výpočet nákladů, takže ho bylo nutné zpřesnit, a do verze 2.0 neměl statistiky pro částečné klíče kompozitních indexů (a doposud nemá histogramy). Rovněž se vylepšovalo vyhodnocování vhodnosti indexů a optimalizátor obecně, a všechny tyto úpravy vskutku započaly s verzí 1.5, takže právě v této době byla v konferencích spousta dotazů na detaily optimalizace.
Problémy s optimalizátorem má ovšem každá databáze, protože cost-based optimalizace není dokonalá (o rule-based nemluvě), takže frekvenci dotazů ani existenci problémových oblastí nelze považovat za důkaz absence optimalizace :-)
Firebird samozřejmě vždy zohledňoval náklady na zpracování indexu. Ono by to bylo dost divné zohledňovat náklady na čtení dat ale už ne indexů, a takového opomenutí by si za těch více než 20 let jistě někdo z vývojářů všiml :-) Pravdou ovšem je, že Firebird zdědil poměrně hrubý vzorec na výpočet nákladů, takže ho bylo nutné zpřesnit, a do verze 2.0 neměl statistiky pro částečné klíče kompozitních indexů (a doposud nemá histogramy). Rovněž se vylepšovalo vyhodnocování vhodnosti indexů a optimalizátor obecně, a všechny tyto úpravy vskutku započaly s verzí 1.5, takže právě v této době byla v konferencích spousta dotazů na detaily optimalizace.
Problémy s optimalizátorem má ovšem každá databáze, protože cost-based optimalizace není dokonalá (o rule-based nemluvě), takže frekvenci dotazů ani existenci problémových oblastí nelze považovat za důkaz absence optimalizace :-)
aura:90
1. 9. 2008 14:16
Nový
Re: Firebird 1.5?
celé vlákno
Bohužel ty odpovědi si fakt nepamatuji - verze Fb 1 a 1.5 mám spojené se slabší optimalizací, a verze řady dvě jako verze, kde tento problém byl nějak vyřešen. Absolutně souhlasím, že problémy s optimalizací jsou všude, včetně PostgreSQL - a řeší se, a asi se ještě budou dlouho řešit. Docela mne překvapilo, kolik změn se letos udělalo na optimalizaci v pg8.4, a to se ještě nezačala řešit otázka závislých sloupců. Zrovna tak se dost překopává optimalizace v MySQL. Moje poznámka byla spíš míněna jako varování před zastaralou verzí Firebirdu, nikoliv před Firebirdem samotným.
Jan Molič (neregistrovaný)
1. 9. 2008 13:36
Nový
dekuji za clanek
celé vlákno
Ačkoli zrovna nyní s postgresem nedělám, je dobré vědět, že na první pohled dva triviální dotazy nemusejí být stejně výhodné. Na hostingovém serveru často zjišťuju, co jsou lidé schopni napsat, vycházejíce z předpokladu, že databáze si s tím nějak poradí (výpis katalogu eshopu 30 sekund není tudíž "nic nenormálního" :-))
evan70 (neregistrovaný)
1. 9. 2008 14:13
Nový
Konecne super clanek :D
celé vlákno
Zdravim vespolek ;)
tak konecne po dlhej dobe super clanok;) maso=zeru
dik
tak konecne po dlhej dobe super clanok;) maso=zeru
dik
xxx (neregistrovaný)
1. 9. 2008 17:42
Nový
efektivita
celé vlákno
zatim jsem se moc nemusel zabyvat efektivitou sql dotazu, mam ale obavy, ze budu
muset v praci zacit :-(
nebylo by marne srovnani jak vyhledavaji ve velkych objemech dat ruzne systemy
na uschovavani dat. srovnani sql databazi, klasickych filesystemu, nastroju pro xml.
protoze bych si tipnul, ze nejake hledaci algoritmy se budou pouzivat
ve vsech techto oborech.
muset v praci zacit :-(
nebylo by marne srovnani jak vyhledavaji ve velkych objemech dat ruzne systemy
na uschovavani dat. srovnani sql databazi, klasickych filesystemu, nastroju pro xml.
protoze bych si tipnul, ze nejake hledaci algoritmy se budou pouzivat
ve vsech techto oborech.
LENIN POWER! (neregistrovaný)
1. 9. 2008 17:55
Nový
cluster index
celé vlákno
neni cluster index nahodou to, ze radky na ktere odkazuje jsou fyzicky zasebou? Alespon tomu se rika v Oracle/db2 index cluster ratio.
podporuje pgsql cluster ratio statistiku u indexu?
podporuje pgsql cluster ratio statistiku u indexu?
aura:90
1. 9. 2008 21:00
Nový
Re: cluster index
celé vlákno
Jako cluster index jsem myslel to, co se používá v MS SQL serveru nebo v InnoDB. Zdeněk Kotala mne upozornil, že v Oracle se tato vlastnost jmenuje Index Organized Tables. Postgres pod příkazem CLUSTER nabízí fyzické seřazení záznamů v tabulce - k seřazení dochází pouze jednorázově - při provedení příkazu. Žádnou speciální statistiku si pg neudržuje - CLUSTER provede pouze jednorázové změny, a časem (díky změnám v tabulce) dojde k porušení pořadí. Tudíž CLUSTER má smysl u ro tabulek nebo u tabulek, kde dochází k minimálním změnám.
Janco (neregistrovaný)
1. 9. 2008 22:34
Nový
Kvalitka
celé vlákno
Zas kvalitny clanok. Uz sa tesim na predstavenie moznosti PostgreSQL 8.4 ;-) Pripadne benchmarky. Ten fulltext bol dost slaby az do verzie 8.3, kde sa dal konecne dobre konfigurovat.
LENIN POWER! (neregistrovaný)
1. 9. 2008 23:15
Nový
Re: Kvalitka
celé vlákno
jestli pgsql neco chybi tak to rozhodne neni rychlost, ktera je pro OLTP workload srovnatelna s Oraclem. V OLAP workloadu na ne pgsql nema: pomalu sorti, pomalu joinuje a neumi ani OLAP queries. V oblasti velkych db taky ne, protoze nema hodne funkcionality potrebne pro efektivni spravu velkych db.
Zdenek Kotala (neregistrovaný)
2. 9. 2008 6:55
Nový
Re: Kvalitka
celé vláknoNo myslim, ze si v prvnich dvou vetach trochu protirecite. Ale ano mate pravdu, ze Postgres neni stejne rychly jako Oracle, ale to si kazdy musi rozhodnout sam, zda mu ta rychlost staci a nebo zda investuje usetrene penize za licence a koupi lepsi zelezo. Podle pruzkumu 80% aplikaci vyuziva pouze 30% vlastnosti enterprise databazi.
Co se tyka tech OLAP queries tak neco by se melo objevit jiz v 8.4. A pro datove sklady existuje bizgress, coz je upravena verze postgresu na zpusob Teradaty.
Zajimalo by mne co myslite velkou databazi a jakou klicovou funkcionalitu Postgres nema?
LENIN POWER! (neregistrovaný)
2. 9. 2008 11:22
Nový
Re: Kvalitka
celé vlákno
pro workload ala lamp Webaplikace na male db stejne rychly je. asi pred tydnem jsme si delali benchmarky ktere to potvrdili. Realna rychlost pgsql8.3 a db2 9 byla uplne stejna pro interaktivni workload. takze rychlost pgsql rozhodne nechybi. Oracle byl pomalejsi, ackoliv ne moc vyrazne, tak o 20%. MySQL 4.1 bylo nejrychlejsi ale ne o moc, tak o 20% oproti pgsql.
pomalejsi je pgsql ve velkych sortech a joinech (rekneme na result setech 40m a vice radek), ale zase ne tak vyrazne, zhruba o 30-40%. zejmena hashjoiny v pgsql jsou velmi pomale pokud se nevejdou do pameti.
pri testovani se db2 nedovolilo aby rozhazovala zatez z 1 klienta mezi vice CPU, to by pak postgres vyklepla, protoze ten to neumi.
pod pojmem velka db si predstavuji databazi obsahujici rozumne velike tabulky, takhle
tablice ma treba ~ 740GB (coz je natolik malo ze se jeste nevyplati saskovat s table partitioningem)
C:\IBM\SQLLIB\BIN>db2 select count(distinct day) from adwords.searches
1
-----------
505
Bylo vybráno 1 záznamů.
C:\IBM\SQLLIB\BIN>db2 select count(*) from adwords.searches where day = current
date - 1 day
1
-----------
55810561
Bylo vybráno 1 záznamů.
Ted koukam ze tablice je nekomprimovana, nanestesti odhadovany space saving rowcompestimate table je 30%, coz mne dost zklamalo, cekal jsem tak 50%.
Take bych si pral zpracovavat takova data, co se smrsknou o 85% jako SAP tablice:
ftp://ftp.software.ibm.com/software/data/pubs/papers/DB2-SAP-compression.pdf
Ja bych tak rad premigroval SAP z Oracle na DB2... nanestesi se to neda udelat uplne bez downtime a my proste bez toho SAPu neprezijeme ani chvili, navic je tu riziko ze downtime bude vetsi nez se puvodne planoval a nejsme nespokojeni s Oracle/SAP ze by byl spatny, ale ze DB2/SAP je lepsi. Mohl bych to zkusit 1.ledna 2009, to snad zakaznici pochopi, kdyz jim to oznamime 3 mesice dopredu.
http://www.sapusers.org/newsletters/2/files/Migrate_your_SAP_solutions_to_DB2-Nov06.pdf
pomalejsi je pgsql ve velkych sortech a joinech (rekneme na result setech 40m a vice radek), ale zase ne tak vyrazne, zhruba o 30-40%. zejmena hashjoiny v pgsql jsou velmi pomale pokud se nevejdou do pameti.
pri testovani se db2 nedovolilo aby rozhazovala zatez z 1 klienta mezi vice CPU, to by pak postgres vyklepla, protoze ten to neumi.
pod pojmem velka db si predstavuji databazi obsahujici rozumne velike tabulky, takhle
tablice ma treba ~ 740GB (coz je natolik malo ze se jeste nevyplati saskovat s table partitioningem)
C:\IBM\SQLLIB\BIN>db2 select count(distinct day) from adwords.searches
1
-----------
505
Bylo vybráno 1 záznamů.
C:\IBM\SQLLIB\BIN>db2 select count(*) from adwords.searches where day = current
date - 1 day
1
-----------
55810561
Bylo vybráno 1 záznamů.
Ted koukam ze tablice je nekomprimovana, nanestesti odhadovany space saving rowcompestimate table je 30%, coz mne dost zklamalo, cekal jsem tak 50%.
Take bych si pral zpracovavat takova data, co se smrsknou o 85% jako SAP tablice:
ftp://ftp.software.ibm.com/software/data/pubs/papers/DB2-SAP-compression.pdf
Ja bych tak rad premigroval SAP z Oracle na DB2... nanestesi se to neda udelat uplne bez downtime a my proste bez toho SAPu neprezijeme ani chvili, navic je tu riziko ze downtime bude vetsi nez se puvodne planoval a nejsme nespokojeni s Oracle/SAP ze by byl spatny, ale ze DB2/SAP je lepsi. Mohl bych to zkusit 1.ledna 2009, to snad zakaznici pochopi, kdyz jim to oznamime 3 mesice dopredu.
http://www.sapusers.org/newsletters/2/files/Migrate_your_SAP_solutions_to_DB2-Nov06.pdf
Zdenek Kotala (neregistrovaný)
2. 9. 2008 13:13
Nový
Re: Kvalitka
celé vlákno
No je pravda, ze tuplestore (takovy swapfile na radky) by si zadal vylepseni. Co se tyce toho rozlozeni zateze na vic CPU to je znacna slabina a je to jeden z cilu pro vyvoj do dalsich verzi. Velikost tabulky v PostgreSQL je omezena 32TB, coz zatim asi nikdo nezkousel :-) nicmene mame zakaznika co ma 2TB tabulku (+3TB v TOAST) bez partitioningu. Funguje to dobre i kdyz to neni uplne svizne.
LENIN POWER! (neregistrovaný)
3. 9. 2008 9:58
Nový
Re: Kvalitka
celé vlákno
Nezlobte se ale radit podnikum (zakaznim v kategorii nesocek) aby si misto Oracle/Db2/mssql vzali zadarmo pgsql a za usetrene prachy za licence koupili lepsi hw muze jen ten kdo ma s IT velmi male zkusenosti nebo ten kdo je silne zainteresovan na prodeji HW.
Zeptejte se Oraclistu (v CR asi nejpocetnejsi skupina z techto db) proc preferuji prave Oracle. Najdete si zde thread LO, LP vs Stehule o tom zda je OSS database vhodna pro vetsi projekt. Je to totiz prilis rizikove a usetrene penize za licenci tohle nevyvazi.
Nedostatky pgsql jsem zde uz dostkrat rozebiral, zkuste vyhledavani. Ja vim ze diskuze s lidmi od Sunu nemaji cenu, absolvoval jsem jich uz mraky a oni moc dobre nechapou realne potreby zakaznika, ziji uplne v jinem svete.
http://www.mysql.com/tcosavings/ -> a ted maminko jeste tu o panu bendovi a o jestircich. Problem je ze lidi opravdu te masazi od Sunu uveri a pak jejich IT podle toho vypada. Pak prijdou k nam s tim svym hnojem a prosi abychom jim to predelali, coz se nam moc nechce, protoze mame prace vic nez stihame, tak si zakazky vybirame.
http://forums.mysql.com/read.php?60,190734,192723#msg-192723
Zeptejte se Oraclistu (v CR asi nejpocetnejsi skupina z techto db) proc preferuji prave Oracle. Najdete si zde thread LO, LP vs Stehule o tom zda je OSS database vhodna pro vetsi projekt. Je to totiz prilis rizikove a usetrene penize za licenci tohle nevyvazi.
Nedostatky pgsql jsem zde uz dostkrat rozebiral, zkuste vyhledavani. Ja vim ze diskuze s lidmi od Sunu nemaji cenu, absolvoval jsem jich uz mraky a oni moc dobre nechapou realne potreby zakaznika, ziji uplne v jinem svete.
http://www.mysql.com/tcosavings/ -> a ted maminko jeste tu o panu bendovi a o jestircich. Problem je ze lidi opravdu te masazi od Sunu uveri a pak jejich IT podle toho vypada. Pak prijdou k nam s tim svym hnojem a prosi abychom jim to predelali, coz se nam moc nechce, protoze mame prace vic nez stihame, tak si zakazky vybirame.
http://forums.mysql.com/read.php?60,190734,192723#msg-192723
aura:90
3. 9. 2008 12:22
Nový
Re: Kvalitka
celé vlákno
Těchto diskuzí tu bylo několik - myslím si, že nemá cenu znovu argumentovat.
http://www.root.cz/zpravicky/prague-postgresql-developers-day-2008/
http://www.root.cz/zpravicky/dubnovy-termin-skoleni-postgresql/
Doporučuji si nepřehlédnout poslední dva příspěvky Radima Koláře
http://www.root.cz/diskuse/2927/204356/vlakno/#o204742
Z mého pohledu cca do 100G databází nejsou s PostgreSQL nejmenší problémy - PostgreSQL se používá i pro 24/7 systémy. Instalací nad 100G je minimum (v poměru k menším než 100G). Já sám se setkávám poměrně často s použitím PostgreSQL jako backendu k request tracker systémům středních podniků (cca do 500 zam) a jako backend ve větších e-shopech. Vím o fakturačních systémech v pekárnách, nemocnicích (ale i ve strojírenství), které běží nad Postgresem. Sám jste argumentoval relativně dobrým výkonem v OLTP. Což je primární segment užití pg - pro OLAP v Pg chybí podpora - budoucí analytické dotazy nebo CTE na tom moc nezmění. To je segment, kam se PostgreSQL netlačí.
http://www.root.cz/zpravicky/prague-postgresql-developers-day-2008/
http://www.root.cz/zpravicky/dubnovy-termin-skoleni-postgresql/
Doporučuji si nepřehlédnout poslední dva příspěvky Radima Koláře
http://www.root.cz/diskuse/2927/204356/vlakno/#o204742
Z mého pohledu cca do 100G databází nejsou s PostgreSQL nejmenší problémy - PostgreSQL se používá i pro 24/7 systémy. Instalací nad 100G je minimum (v poměru k menším než 100G). Já sám se setkávám poměrně často s použitím PostgreSQL jako backendu k request tracker systémům středních podniků (cca do 500 zam) a jako backend ve větších e-shopech. Vím o fakturačních systémech v pekárnách, nemocnicích (ale i ve strojírenství), které běží nad Postgresem. Sám jste argumentoval relativně dobrým výkonem v OLTP. Což je primární segment užití pg - pro OLAP v Pg chybí podpora - budoucí analytické dotazy nebo CTE na tom moc nezmění. To je segment, kam se PostgreSQL netlačí.
LENIN POWER! (neregistrovaný)
5. 9. 2008 19:44
Nový
Re: Kvalitka
celé vlákno
Vas zpusob vyvoje SW je neefektivni. Vy ho sice povazujete za efektivni, ale to je dano tim ze jste inzenyr a ne manager a proto nevidite veci v sirsich souvislotech, ktere zahrnuji kuprikladu vynalozene naklady na lidskou praci, ztrata zpusobena nefukcnosti reseni, cas k realizaci, naklady na udrzbu. Proste spatne pocitate TCO a chybi vam management rizik.
Vzhledem k tomu ze pro pgsql soft prakticky neexistuje, tak predpokladam ze si vsichni zde vyse jmenovani nakodovali reseni inhouse. To je ale dost drahe a neni tu zaruka ze se to vubec uspesne dokonci.
Vzhledem k tomu ze pro pgsql soft prakticky neexistuje, tak predpokladam ze si vsichni zde vyse jmenovani nakodovali reseni inhouse. To je ale dost drahe a neni tu zaruka ze se to vubec uspesne dokonci.
honzak (neregistrovaný)
5. 9. 2008 19:58
Nový
Re: Kvalitka
celé vlákno
...reseni inhouse. To je ale dost drahe ...
ja uz delsi dobu sleduji vase vyplody a musism se priznat, ze tomu vasemu humoru nerozumim. To ze nikdy nepouzivate ironie-tags mi ani nezarazi, to patri k nasi ceske mentalite, presto si myslim, ze je vas humor tak zastreny, ze si nekteri zde mohou myslet, ze to myslite vazne. Navrhuji nejake stylisticke gramatikalni prostredky - slangove slovo, citat nejakeho americkeho herce a nebo neco podobneho, abychom se mohli proste neceho chytit a presne vedet na cem jsme.
Jinak k te vete nahore .... nemohl by jste nam prozradit, co stoji auto.
ja uz delsi dobu sleduji vase vyplody a musism se priznat, ze tomu vasemu humoru nerozumim. To ze nikdy nepouzivate ironie-tags mi ani nezarazi, to patri k nasi ceske mentalite, presto si myslim, ze je vas humor tak zastreny, ze si nekteri zde mohou myslet, ze to myslite vazne. Navrhuji nejake stylisticke gramatikalni prostredky - slangove slovo, citat nejakeho americkeho herce a nebo neco podobneho, abychom se mohli proste neceho chytit a presne vedet na cem jsme.
Jinak k te vete nahore .... nemohl by jste nam prozradit, co stoji auto.
LENIN POWER! (neregistrovaný)
5. 9. 2008 22:17
Nový
Re: Kvalitka
celé vlákno
moje posledni auto stalo asi 32 klacku, mne auta nezajimaji, jinak bych si asi koupil neco drazsiho. Tedy jezdim v jedne licenci Oracle EE.
Jo krome auta mam jeste dve cryrnohe kocky, jednoho psa, spanelsky mluvici sluzku a cernocha zahradnika. Doma mam 2 notebooky, 3 pocitace a 12 Mbit DSLko. Barak ve kterym bydlim stal 450klacku. Dane platim, optimalizaci dani si ale sam nedelam. Dvakrat do tydne chodim strilet a v nedeli jdu do kostela a pred kazdym jidlem se poctive pomodlim. Rano cvicim a do prace jezdim autem. Z televize posloucham CNN a Discovery. Sluzku nebiju.
Potrebujete jeste neco vedet? Klidne se zeptejte.
Jo krome auta mam jeste dve cryrnohe kocky, jednoho psa, spanelsky mluvici sluzku a cernocha zahradnika. Doma mam 2 notebooky, 3 pocitace a 12 Mbit DSLko. Barak ve kterym bydlim stal 450klacku. Dane platim, optimalizaci dani si ale sam nedelam. Dvakrat do tydne chodim strilet a v nedeli jdu do kostela a pred kazdym jidlem se poctive pomodlim. Rano cvicim a do prace jezdim autem. Z televize posloucham CNN a Discovery. Sluzku nebiju.
Potrebujete jeste neco vedet? Klidne se zeptejte.
aura:100
6. 9. 2008 20:08
Nový
Re: Kvalitka
celé vlákno
Mne by zajimalo proc porad tolik podobne jako LO diskutujete na rootu.
aura:100
7. 9. 2008 9:36
Nový
Re: Kvalitka
celé vlákno
Nojo ale ja nedporucuji pgsql protoze by byl idealni, ale protoze nic jineho pouzitelneho zdarma neni (kdyz nepocitame free verzi db2).
Ale tu full implementaci JDBC2 driveru tu by po tech 5ti letech vyvoje uz dodelat mohli.
Ale tu full implementaci JDBC2 driveru tu by po tech 5ti letech vyvoje uz dodelat mohli.
Pavel Stehule (neregistrovaný)
7. 9. 2008 20:12
Nový
Re: Kvalitka
celé vlákno
Ja take netvrdim, ze PostgreSQL je idealni - chybi OLAP, chybi JDBC2 napriklad, implementace partitioningu je stale primitivni, online zalohovani je docela alchymie. Nicmene pro celou radu uloh se kterymi se setkavam, vyhovuje a osvedcuje se. Zalezi na usudku designeru, analytiku, programatoru, jestli PostgreSQL doporuci nebo ne.
aura:100
8. 9. 2008 10:50
Nový
Re: Kvalitka
celé vlákno
nez se mi zmrsil post, mel jsem asi 35 bodu co se mi nelibi na pgsql. Krom toho ja vim ze neni vule tyhle problemy resit a kdyz delate velke projekty tak ty veci opravdu desne vadi, takze pgsql pro velke projekty se sice pouzit da, ale je to vicemene nouzovka nebo pozadavek zakaznika, ktery si mysli ze usetri, coz neusetri. Fajn budeme mit CTE a OLAP ale to nejak vyrazneji pozici pgsql mezi EE db nezlepsi. No a rozpocet velkych projektu ten uz vam dovoli si Oracle za $15k koupit, protoze je to kapka v mori, vzhledem k cene lidske prace.
Ja jsem s pgsql delal opravdu dost velky projekty, ale dneska po tech 5+ letech zkusenosti s nim bych ho jiz pro tenhle druh aplikaci nepouzil pokud by ho zakaznich neprosazoval. Neni to dobra volba. Existuje ovsem rada projektu kde by nevydelaly ani na licenci Oraclu, o jeho provoznich nakladech ani nemluve a tyto projekty by bez mysql/php/pgsql ani nevznikly.
Napriklad podpora toolu je v postgresql uplne tragicka, dale podpora profi zalohovacich systemu neni, pgsql nemi delat XA TM, SQLJ neni, diky flaky JDBC2 driveru nefunguji ani takove zakladni tooly jako BIRT i kdyz pravda reportovaci tooly pouzivaji casto JDBC3 api pro databaze metadata (ktere pgsql driver neumi).
Krom toho vyvojari pgsql nikdy nerespektuji de facto standardy dane Oraclem (kuprikladu jak se ma databaze semanticky chovat pro zamykani updatable cursoru). Kdyz si treba vezmeme zamykani v databazich tak kazda z db pouziva jiny model, zamykani dat je kriticke pro obranu pred races a prepisovat zamykaci model je pomerne narocna prace, protoze se to musi delat velmi peclive.
oracle (zamyka nejvice)
db2/cloudscape
firebird
postgres (zamyka nejmene)
Neexistence hintu dost vadi, nemuzete zamykat access plan aby se dal garantovat service level, replikace je primitivni, smutnym faktem je ze z replikaci pro pgsql je slony nejlepsi a neumi ani tak zakladni vec jako si vybrat ktere radky/sloupce vlastne chcete replikovat. Navic obnova databaze ze zalohy znici slony instalaci, takze musite ho odinstalovat, nainstalovat znova a znovu sesynchronizovat db.
Ta freeware DB2 co tu inzeroval lenin je velmi vyrazne lepsi nez pgsql a je za stejnou cenu (zdarma), ackoliv se za nejake featury (HA a Replikace) plati, ale dostanete k nim i 24/7 support, ktery by si zakaznik delajici vetsi projekt stejne koupil (navic musite zohlednit fakt ze slony1 je pomerne problematicke v produkci a support pro nej nikdo v cz neprodava). Prakticky je tak databaze zdarma a platite jen za support. Problem je ze Cesi DB2 nechteji, tuhle db vidim v produkci nasazenou ale opravdu velmi vzacne.
Ja vim databazi zase tak moc neni: mysql, db2, oracle, pgsql. Mysql ma ale vybornou podoporu nastroju, snad kazdy profi nastroj umi dneska i mysql a lidi co umeji delat s mysql jsou _velmi_ levni, dostupni a bohuzel take velmi nekvalitni, ostatne kvalita mysql je opravdu velmi nizka, donedavna jeste vracela pri joinech chybne vysledky a 5.0 ma problemy s views, ktere nekdy spatne vyhodnoti. Ja bych mysql ale neriskoval pro aplikaci ktera zachazi s penezi na blog/webforum je to ok, tam o nic nejde.
PGSQL ma tu vyhodu ze z vyse uvedenych databazich nejmene havaruje diky internim SW chybam, oracle a mysql nejvice. Idealni databaze pro install & forget aplikace. Ja Oracle sice vubec rad nemam pro znacnou poruchovost v produkci (zejmena pri nasazeni v RAC), ale cesi ho maji radi a dobre se pro nej programuje.
Ja jsem s pgsql delal opravdu dost velky projekty, ale dneska po tech 5+ letech zkusenosti s nim bych ho jiz pro tenhle druh aplikaci nepouzil pokud by ho zakaznich neprosazoval. Neni to dobra volba. Existuje ovsem rada projektu kde by nevydelaly ani na licenci Oraclu, o jeho provoznich nakladech ani nemluve a tyto projekty by bez mysql/php/pgsql ani nevznikly.
Napriklad podpora toolu je v postgresql uplne tragicka, dale podpora profi zalohovacich systemu neni, pgsql nemi delat XA TM, SQLJ neni, diky flaky JDBC2 driveru nefunguji ani takove zakladni tooly jako BIRT i kdyz pravda reportovaci tooly pouzivaji casto JDBC3 api pro databaze metadata (ktere pgsql driver neumi).
Krom toho vyvojari pgsql nikdy nerespektuji de facto standardy dane Oraclem (kuprikladu jak se ma databaze semanticky chovat pro zamykani updatable cursoru). Kdyz si treba vezmeme zamykani v databazich tak kazda z db pouziva jiny model, zamykani dat je kriticke pro obranu pred races a prepisovat zamykaci model je pomerne narocna prace, protoze se to musi delat velmi peclive.
oracle (zamyka nejvice)
db2/cloudscape
firebird
postgres (zamyka nejmene)
Neexistence hintu dost vadi, nemuzete zamykat access plan aby se dal garantovat service level, replikace je primitivni, smutnym faktem je ze z replikaci pro pgsql je slony nejlepsi a neumi ani tak zakladni vec jako si vybrat ktere radky/sloupce vlastne chcete replikovat. Navic obnova databaze ze zalohy znici slony instalaci, takze musite ho odinstalovat, nainstalovat znova a znovu sesynchronizovat db.
Ta freeware DB2 co tu inzeroval lenin je velmi vyrazne lepsi nez pgsql a je za stejnou cenu (zdarma), ackoliv se za nejake featury (HA a Replikace) plati, ale dostanete k nim i 24/7 support, ktery by si zakaznik delajici vetsi projekt stejne koupil (navic musite zohlednit fakt ze slony1 je pomerne problematicke v produkci a support pro nej nikdo v cz neprodava). Prakticky je tak databaze zdarma a platite jen za support. Problem je ze Cesi DB2 nechteji, tuhle db vidim v produkci nasazenou ale opravdu velmi vzacne.
Ja vim databazi zase tak moc neni: mysql, db2, oracle, pgsql. Mysql ma ale vybornou podoporu nastroju, snad kazdy profi nastroj umi dneska i mysql a lidi co umeji delat s mysql jsou _velmi_ levni, dostupni a bohuzel take velmi nekvalitni, ostatne kvalita mysql je opravdu velmi nizka, donedavna jeste vracela pri joinech chybne vysledky a 5.0 ma problemy s views, ktere nekdy spatne vyhodnoti. Ja bych mysql ale neriskoval pro aplikaci ktera zachazi s penezi na blog/webforum je to ok, tam o nic nejde.
PGSQL ma tu vyhodu ze z vyse uvedenych databazich nejmene havaruje diky internim SW chybam, oracle a mysql nejvice. Idealni databaze pro install & forget aplikace. Ja Oracle sice vubec rad nemam pro znacnou poruchovost v produkci (zejmena pri nasazeni v RAC), ale cesi ho maji radi a dobre se pro nej programuje.
aura:90
8. 9. 2008 12:45
Nový
Re: Kvalitka
celé vlákno
Já bych také rád viděl některé funkce z Oracle nebo DB2 v PosgreSQL. To co není ve standardu se ale docela dost obtížně prosazuje - navíc standard neobsahuje některé zajímavé funkce, které jsou jak v DB2, tak v Oracle - ale jinak implementované. Je fakt dost velký odpor k implementaci duplicitní syntaxe - i když je to pár řádku v gramatice, a i když historicky PostgreSQL určitou kompatibilitu s Oraclem nabízel. S drivery je to jednoduché - v podstatě, co kdo napíše, to je. Fakt je ten, že .NET komunita je o dost aktivnější.
RK (neregistrovaný)
9. 9. 2008 12:46
Nový
Re: Kvalitka
celé vlákno
Problem je ze zpusob jakym je pgsql projekt veden. Proste vedeni projektu kasle na lidi kteri by radi z pgsql meli databazi srovnatelnou s oracle/db2. Pod pojmem srovnatelna myslim to, aby byla pouzitelna pro vetsi projekty.
LO i Lenin maji pravdu s tou zpetnou vazbou, ktera proste bez penez nefunguje.
Pokud pridavate feature X (writeable cursory) tak zakaznici oceni zamykaci model kompatibilni s Oracle nebo v horsim pripade s DB2, protoze jim kompatibilita usetri mnoho casu (a tudiz i penez). Budou s produktem spokojeni a budou dale platit a neposilhavat po konkurenci.
Kdyz ovsem zpetna vazba od uzivatelu neni, tak vas nic nenuti se starat o jejich blaho a tak pokud danou vec nespecifikuje SQL standard presne, udelate si to proste podle sebe (t.j. nekompatibilne) a uzivatele maji smulu. Proste se musi prizpusobit.
Pritom mne lidi z EDB, kteri nejsou v pgsql komunite moc oblibeni nepripadaji jako ze by chteli neco nerealneho, proste chapou potreby svych zakazniku, kteri by se radi venovali svemu byznisu a ne ztraceli cas s databazi. Pokud ma ovsem nekdo vyvoj pgsql jako konicka tak ja ho chapu, tyhle problemy ho asi netrapi.
Kompatibilita s de facto standardem je dobra vec. A nechapu proc jsou opravdu tak zasadne proti syntax sugaru. Komu by vadilo ze pgsql umi i oracle kompatibilni syntax rekneme pro sekvence? mne ne.
LO i Lenin maji pravdu s tou zpetnou vazbou, ktera proste bez penez nefunguje.
Pokud pridavate feature X (writeable cursory) tak zakaznici oceni zamykaci model kompatibilni s Oracle nebo v horsim pripade s DB2, protoze jim kompatibilita usetri mnoho casu (a tudiz i penez). Budou s produktem spokojeni a budou dale platit a neposilhavat po konkurenci.
Kdyz ovsem zpetna vazba od uzivatelu neni, tak vas nic nenuti se starat o jejich blaho a tak pokud danou vec nespecifikuje SQL standard presne, udelate si to proste podle sebe (t.j. nekompatibilne) a uzivatele maji smulu. Proste se musi prizpusobit.
Pritom mne lidi z EDB, kteri nejsou v pgsql komunite moc oblibeni nepripadaji jako ze by chteli neco nerealneho, proste chapou potreby svych zakazniku, kteri by se radi venovali svemu byznisu a ne ztraceli cas s databazi. Pokud ma ovsem nekdo vyvoj pgsql jako konicka tak ja ho chapu, tyhle problemy ho asi netrapi.
Kompatibilita s de facto standardem je dobra vec. A nechapu proc jsou opravdu tak zasadne proti syntax sugaru. Komu by vadilo ze pgsql umi i oracle kompatibilni syntax rekneme pro sekvence? mne ne.
aura:90
9. 9. 2008 15:40
Nový
Re: Kvalitka
celé vlákno
Problém s Oraclem je asi následující - Oracle si bere standard jen jako inspiraci - celkem logicky se snaží o vytvoření vlastního standardu a o vendor lock. Něco implementuje podle standardu, něco nikoliv (např. chybí operátor DISTINCT OF). Není problém implementovat dvě syntaxe (většinou, pokud nedojde ke kolizi). Problém je v dokumentaci a ve vývoji - výsledkem je takový kočkopes - (což už tedy PostgreSQL stejně je). V okamžiku, kdy jednu věc můžete napsat 4x trpí kvalita kódu a paradoxně přenositelnost (i když přenositelnost u komplikovanějších aplikací je utopie). Zavedením režimů kompatibility zase dost bobtná parser, což pak znamená vyšší režii na údržbu a vývoj. Existence EDB se ukázala jako docela přínosná v tom, že se nemusela řešit kompatibilita s Oraclem - tu si řešila EDB. Mimochodem - neoblíbenost EDB v komunitě není nijak zásadní - stále jsou v EDB zaměstnáni klíčoví vývojáři - a nikdo EDB nevyčítá, že používá kód PostgreSQL. Takových firem je více a EDB alespoň sponzoruje vývoj. Marketingu EDB se ovšem povedlo vyprodukovat několik nešťastných neobjektivních tiskových prohlášení - čímž si komunitu rozhodně nezískali.
aura:100
10. 9. 2008 13:07
Nový
informix
celé vlákno
je fakt ze existuje jeste informix, ktery ibm v soucasnosti marketingove tlaci pro OLTP aplikace aby se vratily naklady na jeho vyvoj. Argumentuje vykonem a HA featurama, ale zadne tpc benchmarky k dispozici nejsou a cena je stejna jako za db2. Ale i kdyby byl opensource, pochybuji ze by nekoho zaujal tak ze by na nej premigroval.
Driv se ho snazila ibm zbavit, ale ukazalo se ze nektere organizace (treba VISA) z informuxu migrovat nechteji, nechce se jim prepisovat aplikace. Presto pocet uzivatelu informixu rok od roku klesa, ja osobne bych informix pro nove aplikace jiz nepouzil.
Na trhu databazi jiz pro nej neni misto. Stejne tak neni misto pro SAPDB, na tu se pamatuji a bylo to tak zabugovane, ze mne neprekvapuje ze ji dneska nikdo nechce ackoliv je pod GPL a featurelist nema rozhodne nejhorsi. Pres 70% SAPu beha na Oraclu. IT prumysl potrebuje co nejmene ruznych databazi, ponevadz jsou navzajem nekompatibilni - protoze jak je videt na prikladu pgsql - oni se na vicemene standardu proste neschodnou a zamykani ma kazda databaze semanticky uplne jine. Kdyz kuprikladu hodite pgsql kod do db2, tak zamykani (select for update) nebude vubec fungovat. Prenositelnost i velmi jednoduchych aplikaci je proto utopie.
http://www.google.cz/url?sa=t&source=web&ct=res&cd=32&url=http%3A%2F%2Fevents.ibm-smb.cz%2Fforum2008%2F5_DatabazovaReseniIBM.pps&ei=M4jHSJyHFI--0gWTwJkT&usg=AFQjCNGFS6CxTM0XdybyHj81XluQ8VmLYg&sig2=yonFS1qy6sStT1lqdQe0CQ
ja jsem s informixem pracoval naposledy tak pred 10 lety a to byla hrozne zabugovana databaze. Osobne bych rad videl kdyby firebird, informix a sybase uz konecne odkraceli do vecnych lovist. Oni umiraji pomalu, protoze nikdo je uz pro nove aplikace je uz nechce.
Prekvapive mainframova IMS z roku 1960 je dodnes nejpouzivanejsi databazi na mainframech. Ukazuje to hezky na fakt, ze ne vzdy je SQL dotazovaci jazyk potreba. S IMS jsem jiz delal, ale jeste jsem nedelal zadnou aplikaci pro CICS, to bych si taky jeste chctel zkusit.
Driv se ho snazila ibm zbavit, ale ukazalo se ze nektere organizace (treba VISA) z informuxu migrovat nechteji, nechce se jim prepisovat aplikace. Presto pocet uzivatelu informixu rok od roku klesa, ja osobne bych informix pro nove aplikace jiz nepouzil.
Na trhu databazi jiz pro nej neni misto. Stejne tak neni misto pro SAPDB, na tu se pamatuji a bylo to tak zabugovane, ze mne neprekvapuje ze ji dneska nikdo nechce ackoliv je pod GPL a featurelist nema rozhodne nejhorsi. Pres 70% SAPu beha na Oraclu. IT prumysl potrebuje co nejmene ruznych databazi, ponevadz jsou navzajem nekompatibilni - protoze jak je videt na prikladu pgsql - oni se na vicemene standardu proste neschodnou a zamykani ma kazda databaze semanticky uplne jine. Kdyz kuprikladu hodite pgsql kod do db2, tak zamykani (select for update) nebude vubec fungovat. Prenositelnost i velmi jednoduchych aplikaci je proto utopie.
http://www.google.cz/url?sa=t&source=web&ct=res&cd=32&url=http%3A%2F%2Fevents.ibm-smb.cz%2Fforum2008%2F5_DatabazovaReseniIBM.pps&ei=M4jHSJyHFI--0gWTwJkT&usg=AFQjCNGFS6CxTM0XdybyHj81XluQ8VmLYg&sig2=yonFS1qy6sStT1lqdQe0CQ
ja jsem s informixem pracoval naposledy tak pred 10 lety a to byla hrozne zabugovana databaze. Osobne bych rad videl kdyby firebird, informix a sybase uz konecne odkraceli do vecnych lovist. Oni umiraji pomalu, protoze nikdo je uz pro nove aplikace je uz nechce.
Prekvapive mainframova IMS z roku 1960 je dodnes nejpouzivanejsi databazi na mainframech. Ukazuje to hezky na fakt, ze ne vzdy je SQL dotazovaci jazyk potreba. S IMS jsem jiz delal, ale jeste jsem nedelal zadnou aplikaci pro CICS, to bych si taky jeste chctel zkusit.
honzak (neregistrovaný)
8. 9. 2008 13:54
Nový
Re: Kvalitka
celé vlákno
ja skutecne nechapu, co s tim sledujete. Je to takovy povzdech nad nedokonalym svetem nebo si skutecne prejete, aby vznikla nejaka postgresql, ktera by mela vsechny klady tech ostatnich DB bez vsech vlastnich a cizich nevyhod?
Z toho co pisete by mel clovek dojem, ze bez DB2 nemuze byt lidstvo spokjeno. Ale napr. v Nemecku je 2 miliony firem, ktere maji mene nez 10 zamestnanci. Pak dalsi 1 milion firem, ktere maji do 50 zamestnancu nebo tak 20 milionu EUR obrat. Pro ty mensi firmy staci sprava dat ve filesystemu, ty vetsi (moje osobni zkusenost) maji tak do 10GB dat. Jenom nekolik stovek firem v nejakem state ma 100GB dat.
Otazka tedy musi znit, pro koho se tady vyviji a kdo bude nakukovat ty provadeci plany?
Z toho co pisete by mel clovek dojem, ze bez DB2 nemuze byt lidstvo spokjeno. Ale napr. v Nemecku je 2 miliony firem, ktere maji mene nez 10 zamestnanci. Pak dalsi 1 milion firem, ktere maji do 50 zamestnancu nebo tak 20 milionu EUR obrat. Pro ty mensi firmy staci sprava dat ve filesystemu, ty vetsi (moje osobni zkusenost) maji tak do 10GB dat. Jenom nekolik stovek firem v nejakem state ma 100GB dat.
Otazka tedy musi znit, pro koho se tady vyviji a kdo bude nakukovat ty provadeci plany?
LENIN POWER! (neregistrovaný)
7. 9. 2008 14:22
Nový
rychlost backupu PGSQL
celé vlákno
pgdump o velikosti 2.8 GB.
Doba zalohy - 779.46 real 27.62 user 15.41 sys
doba obnovy - 3392.39 real 25.33 user 16.72 sys
velikost db na disku:
originalni db 8.6 GB
obnovena db 7.1 GB
to jako platforma pro 100GB databaze nevypada, vzdyt by obnova znamenala alespon 1 denni vypadek. Takze se da pouzit pokud cena jednodeniho vypadku + slozitejsiho vyvoje < cena licence mssql/db2/oracle. Tedy jen pro amaterske pouziti.
Pro zajimavost restore 100GB DB2 ze stejneho diskoveho pole 19 minut. Jo, je to kapanek rychlejsi.
Doba zalohy - 779.46 real 27.62 user 15.41 sys
doba obnovy - 3392.39 real 25.33 user 16.72 sys
velikost db na disku:
originalni db 8.6 GB
obnovena db 7.1 GB
to jako platforma pro 100GB databaze nevypada, vzdyt by obnova znamenala alespon 1 denni vypadek. Takze se da pouzit pokud cena jednodeniho vypadku + slozitejsiho vyvoje < cena licence mssql/db2/oracle. Tedy jen pro amaterske pouziti.
Pro zajimavost restore 100GB DB2 ze stejneho diskoveho pole 19 minut. Jo, je to kapanek rychlejsi.
Pavel Stehule (neregistrovaný)
7. 9. 2008 20:03
Nový
Re: rychlost backupu PGSQL
celé vlákno
100GB databazi nikdo soudny nebude zalohovat dumpem do SQL. Od toho je online zaloha.
honzak (neregistrovaný)
2. 9. 2008 15:30
Nový
pro aplikacniho vyvojare ?
celé vlákno
neco se mi na te dnesni db-technologii nelibi. Nebo jak si to mam predstavit?. Jiste to neni mysleno tak, ze aplikacni vyvojar se zabyva s tim, co je zde popsano. Aplikacni vyvojar se stara o to, aby zakaznik dostal optimalni reseni. To uz je tezke dost na to, aby studoval nejake provadeci plany.
Kdo se s tim tedy zabyva.? Tusim, ze firma ktera vyviji aplikace tedy zamestnava jednoho takove systemoveho db specialistu, ktery pri nesnazich nahlizi ty provadeci plany a meni pak ty dotazy. Vyplati se nekdo takovy? Jak je to skutecne ve firmach organizovano?
Kdo se s tim tedy zabyva.? Tusim, ze firma ktera vyviji aplikace tedy zamestnava jednoho takove systemoveho db specialistu, ktery pri nesnazich nahlizi ty provadeci plany a meni pak ty dotazy. Vyplati se nekdo takovy? Jak je to skutecne ve firmach organizovano?
aura:90
2. 9. 2008 16:13
Nový
Re: pro aplikacniho vyvojare ?
celé vlákno
Začnu z druhé strany - otázkou. Co je to aplikační vývojář - kodér nebo programátor? Ke znalostem aplikačního programátora by rozhodně mělo patřit jak SQL, tak i schopnost alespoň základního ověřování a optimalizace SQL dotazů. Programátor bez znalosti db napáchá víc škody než užitku. V určitém objemu dat to není tak složitého, což jsem se snažil vysvětlit v tomto článku. Dokonce je to velice jednoduché. Práce pro specialisty začíná v okamžiku, kdy se velikost databáze přehoupne přes určitou laťku - pak už je potřeba dost znalostí, které běžný programátor nemusí mít.
Pokud vím, tak řada firem zaměstnává DB specialisty - na různých pozicích a osobně si myslím, že se jim to velice vyplatí. Sám jsem rozhýbával několik líných a více-méně nepoužitelných aplikací - přičemž zrychlení bylo jasně prokazatelné - cca 50-100% celkového strojového času databáze. Rozhýbal jsem systémy, které již byly nepoužitelné. Nemohu ale říci, že bych k tomu potřeboval speciální know-how. Většina brzd je do očí bijící pitomě napsaný kód.
Pokud vím, tak řada firem zaměstnává DB specialisty - na různých pozicích a osobně si myslím, že se jim to velice vyplatí. Sám jsem rozhýbával několik líných a více-méně nepoužitelných aplikací - přičemž zrychlení bylo jasně prokazatelné - cca 50-100% celkového strojového času databáze. Rozhýbal jsem systémy, které již byly nepoužitelné. Nemohu ale říci, že bych k tomu potřeboval speciální know-how. Většina brzd je do očí bijící pitomě napsaný kód.
surda (neregistrovaný)
2. 9. 2008 22:41
Nový
Dik za perfektni clanek
celé vlákno
potvrdil nektere vlastni objevy a dukladne rozsiril vedomosti kudy dal. Mensi DB ( v radu jednotek az desitek GB) se chovaly korektne, pouzivaly pripravene indexy, pri narustu pres 100GB nezbylo nez zvysit cenu sekvencniho cteni. Po precteni tohoto clanku budeme dal experimentovat. Jeste bych upozornil na jednu vec, ktera by se nikdy nemela stat, ale bohuzel, stane se nam casto na malych ad-hoc tabulkach, primarni klic napriklad varchar a ve velke tabulce foreign int a i kdyz je zaindexovan, postgres index nepouzije, protoze nedela automatickou konverzi typu a je nutne na neindexovane strane doplnit pretypovani ::int.
Postgres je perfektni a pokud se objevi i oracli analyticke rozsireni, tak nevidim rozumny duvod k pouzivani oracle. K tomu cast analytickeho rozsireni se da delat workaroundy uz nyni ...
Dik
Postgres je perfektni a pokud se objevi i oracli analyticke rozsireni, tak nevidim rozumny duvod k pouzivani oracle. K tomu cast analytickeho rozsireni se da delat workaroundy uz nyni ...
Dik
aura:90
3. 9. 2008 9:18
Nový
Re: Dik za perfektni clanek
celé vlákno
PostgreSQL indexy použije, pokud existuje implicitní konverze a to ještě pouze pro rovnost. Pro ostatní operátory musí být stejné typy na obou stranách. Ve všech ostatních případech je nutné explicitní přetypování. Což asi lepší nebude - je snaha o minimalizaci počtu implicitních konverzí. Na druhou stranu by se mohlo objevit alespoň varování, proč se ten či onen index nepoužije - tohle leckoho nekopne. Toho, co by se dalo dělat, je hodně.
p.s. těší mne, že tahle práce, má nějaký efekt.
p.s. těší mne, že tahle práce, má nějaký efekt.
anonYmouse (neregistrovaný)
4. 9. 2008 15:51
Nový
vyborny clanek
celé vlákno
diky za nej
jeste by mozna bylo vyborne trochu poresit GUCS (viz v clanku zminka o work_mem), nebot jejich spravne nastaveni strasne moc ovlivnuje celkovy vykon databaze. Na webu moc srozumitelnych informaci na toto tema k nalezeni neni
dobre jsou i odkazy, treba ten o Desateru, ktere by mozna klidne vydalo na deset samostatnnych clanku na rootu :)
jeste by mozna bylo vyborne trochu poresit GUCS (viz v clanku zminka o work_mem), nebot jejich spravne nastaveni strasne moc ovlivnuje celkovy vykon databaze. Na webu moc srozumitelnych informaci na toto tema k nalezeni neni
dobre jsou i odkazy, treba ten o Desateru, ktere by mozna klidne vydalo na deset samostatnnych clanku na rootu :)
aura:90
8. 9. 2008 12:18
Nový
Re: vyborny clanek
celé vlákno
Doporučil bych Joshuovy slajdy: http://www.pgcon.org/2008/schedule/events/104.en.html
