U rekurzivnich dotazu je problem v tom, ze rekurzivni vyrazy psal nekdo z EDB jenze samozrejme jako CONNECT BY kvuli tomu jejich kopirovani Oracle a prislo se na to, ze WITH RECURSIVE (podle standardu) se bude muset napsat znovu, proto to tak dlouho trva.
Podobne je to s analytickymi dotazy, Gavin to ma prakticky hotove uz nejakou dobu, ale pro Bizgres MPP a prelit to do codebase Postgresu tak aby to splnovalo naroky na kvalitu kodu nebylo realne stihnutelne (aspon mi to tak rikal).
Jinak z EDB ted nedavno 2 vyvojari odesli coz osobne vidim jako pozitivni vec.
Neviete ci existuje nejaky XML standard vymeny dat medzi DB a klientom? Robim take 3-vrstvove rozhranie k db a nerad by som vymyslal nieco co uz bolo vymyslene. Vdaka
No neviem ci je to presno to co mam na mysli, ja robim sietovu vrstvu, cize data ktore sa vracaju spat z databazy po sieti. Existuje nejake nastavenie postgresu (alebo inej db) ktore hovori "posielaj mi vyselektovane data spat vo forme xml suboru" s tym ze by to bolo (v idealnom priapade) rovnake pre rozne databazy (oracle, mysql, firebird)? Lebo normalne ma kazda db tusim svoj vlastny format dat, obvykle binarny.
Na urovni databazi nevim o nicem podobnem. Vim, ze Sybase a MSSQL sdili binarni format, ktery urcite neni XML. Rozhodne nic takoveho neexistuje v PostgreSQL a dal bych ruku do ohne ze to nebude ani ve Firebirdu nebo MySQL.
sleduji ty clanky o postgresql jiz od dobb, kdy to tu psal pan Zak. Uz tehdy pry byla psql velmi rychla. A z kazdou verzi se razantne zvysila rychlost. Jsem rad, ze je tomu tak, v pristi verzi ocekavam, ze jeste nez napisu nejaky dotaz, tak ze uz bude proveden ...
+1 :-)))) to vies nie je problem zobrat vzdy nejaku jednu operaciu z miliona a RAZANTNE zvysit jej rychlost - a potom to akoze nenapadne naznacovat ze je to tak aj pre celok :)
"The perfect is the enemy of the good" (Voltaire).
Nejsem sam a clanek to take naznacuje kdo nebyl uplne spokojen s stylem vyvoje. Bohuzel nekteri z hlavnich vyvojaru jsou trosku odtrzeni od reality a realneho pouzivani PG v produkcnim prostredi. Bylo (a asi i nadale je) problem dostat do projektu kod, ktery je v realu hodne zajimavy pro urcitou skupinu uzivatelu, ale bohuzel neni akademicky perfektni. Verim, ze by se tento problem mohl castecne vyresil tlakem ze strany EnterpriseDB, ktera bude asi otevrenejsi k zakaznikum/uzivatelum.
BTW, takto velky projekt s velkou ruznorodosti jak v moznem vyvoji tak v integrovanych features by mel pouzivat distribuovany version control system a nelinearni vyvoj. INBOX jako prekladiste patchu se neosvedcil v pripade Linuse a neni duvod proc by to v pripade Bruceho melo byt jine...
Zas jeden vinikajuci clanok na roote. Musim povedat ze clanky Pavela Stahulu maju svoju kvalitu. Dobre napisane, hutne, k veci.
Ak mozem podpichnut bude aj nejaky benchmark novej verzie oproti tym ostatnym? ;-)
V pgbenchi je to zhruba 615 t/s vuci 530 t/s (8.2). Co jsem si vsiml, tak v pgbenchi nepada tak strme vykon s vetsim poctem klientu jako u starsich verzich. Osobne pgbench test na mem notebooku jiz beru vice mene orientacne, prim uz hraji vice procesorove servery, a ty v notesu nemam.
rad bych se zeptal autora jak realisticky vidi moznost upravy zdrojoveho kodu psql pro nasledujici pripad. V nekterych databazich (solid, adabas, sapdb, sybase, cql++) je umozneno ruznym zpusobem v kritickych situacich obejit parser(castecne),planovac a optimizer. Budto je k dispozici nejaka API, ktera umozni pristup k jednotlivym radkam bez pouziti SQL nebo (jako napr. adabas) existuji rozsirene SQL Selects, ktere naviguji primo v tabulce pres prim-key nebo indexy.
Jako open-source je u psql vubec sance neco takoveho udelat. Ale je ta sance vubec realna? Musi byt napr. realizator nekdo z core-teamu.
Obávám se, že takový API do postgresu nepropašuješ viz. http://www.postgresql.org/docs/faqs.TODO.html (Kaptiola: "Features We Do Not Want") Zároveň bych se chtěl zeptat, zda jsi narazil na dotaz, kde je potřeba optimizeru napovědět.
Mě by zajímala 'fíčura' "Add optional textual message to NOTIFY", ale jak na to?
Mam pocit, ze jeden pokus uz tady byl. Problem je nekde jinde. Tom Lane chce toto rozsireni spojit s refaktoringem NOTIFY, ktery ma problemy - ktere se pak objevuji pri extremne vysokem loadu, a ktere se pak prenasi do dalsich aplikaci (slony, atd)
asi jsem se spatne vyjadril. V obou Vami citovanych databazich je stejny problem, umoznuji pristup pouze pres vice-mene standardizovane SQL rozhrani. Jde o to, za kolik (nebo za jak dlouho) by jste napr. byl Vy treba schopen takovou upravu provest.
Do takhle nizkourovnovych veci bych se ja nepoustel. Je to minimalne 14 dni-mesic prace. K datovemu souboru se nepristupuje primo, ale prostrednictvim nekolika urovnove cache, atd. Update v Pg neznamena fyzicke prepsani zaznamu, ale vytvoreni nove verze, modifikaci indexu, atd.. Zas na druhou stranu by to az tak komplikovane byt nemuselo. Hodne by se dalo vybrakovat ze stavajiciho reseni Large Objects, ktere SQL take obchazi. Cenove, cca kolem 40-60K. Jelikoz je to, do jiste miry, duplicitni stavajici podpore kurzoru (PostgreSQL podporuje i updatable kurzory), tak si myslim, ze by to bylo naprosto bez sance na commit do Postgresu. K tomu jeste, planovani dotazu (aparat SQL) ma natolik minimalni rezii, ze neverim, ze byste si nejak zvlast timto rozhranim pomohl.
[...] Jelikoz je to, do jiste miry, duplicitni stavajici podpore kurzoru [...]
ale i cursor prece vytvori nejakou vysledkovou mnozinu z ktere je sice mozno radku po radce precist, ale casove je problem vytvoreni te vysledkove mnoziny.
Dekuji za Vas tip a za ten odhad, je to takovy smutny priklad, jak ten open source vlastne nefunguje.
Ale funguje. Jenže o.s. nemá nahrazovat nějaký komerční soft s tím, že jediný rozdíl je v tom, že je zadarmo. Stejně tak programátoři, i open source, nejsou samaritáni. o.s. vám umožňuje vždy vytvořit vlastní fork a doplnit do něj funkcionalitu, kterou požadujete. Pokud přesvědčíte ostatní, že vámi vytvořená funkce je užitečná i pro ostatní, tak je pravděpodobné, že se zařadí do hlavního stromu a vy se dál o svůj kód nebudete muset starat a budete mít výhodu, že nebudete muset provádět merge svého a hlavního kódu, což stojí čas a peníze. Což je taky jediný důvod, proč komerční fy. platí programátory, aby pracovali na o.s. Kdyby se do kódu přidával každá funkce, kterou si někdo vymyslel, tak jak by to dopadlo?
Jinak k tomu vašemu problému. Věřte mi, že režie SQL je minimální. Hrdlo je čtení z disku, případně zámky. Režie SQL pro sekvenční čtení (případně podporované indexy) je zanedbatelná (zvláště pokud se použijí prepared statements). Navíc, pokud Vám jde o rychlý přístup k jednoduchům datům, kdy nepotřebujete SQL, tak PostgreSQL není pro Vás to pravé ořechové. Vzhledemk MVCC budou vždy rychlejší klasické databáze, jako je MySQL (MYISAM) nebo SQLite.
Srovnavani firebirdu a PQSQL/MYSQL mi prijde jako paradni vtip :D. Srovnavat engine, ktery je cistejsi (rozumej - ne tak precpany volovinama) nez Oracle, stabilnejsi a vykonnejsi s "hrackama" typu MySQL je stale a porad asi jako srovnavat "nalesteneho trabanta" s raketoplanem. Duvody by vydaly ne na clanek, ale knihu, kazdy prumerne inteligentni ctenar root.cz si jiste bude schopen duvody vygooglit.
PgSQL
-je starsi (tzn. odladenejsi)
-komplexnejsi (poskytuje pokrocile DB funkce a je vykonnejsi pro rozsahle DB)
-dodrzuje standard SQL92
MySQL
-je mladsi (tzn. mene odladene)
-primitivni (neposkytuje pokrocile DB funkce a ma nizky vykon s rozsahlymi DB a vysoky s malymi)
-nedodrzuje standard SQL92, proto se jmenuje > My < SQL, tzn. neni SQL compliant.
Ci je projekt starsi alebo nie neznaci nic o jeho odladenosti. Ak musim robit nejaku novu vec tak uz len z dovodu, ze niektory projekt ma viac rokov bude kvalita kodu lepsia ? Akoze s vekom rastie chut ? :)
Primitivny-neprimitivny. Definuj funkcie, bez ktorych nemozes "zit". Inak kecas. Mne napriklad v MySQL chybaju stlpce typu Array a nemusel riesit niektore veci vo viacerych riadkoch.
MySQL je kompatibilna podla normy SQL92.
A ze sa vola My je kvoli tomu, ze chcelo preniknut z akademickej a korporatnej sfery medzi sirsiu verejnost vdaka svojej jednoduchosti. Co sa mu aj podarilo.
Protoze by to nebyla pravda. Kvalita kodu nezalezi na stari projektu. Dokonce bych si troufal tvrdit, ze novejsi lepe navrzene projekty mohou byt kvalitnejsi. Navic PostgreSQL prochazi neustalou refaktorizaci. Pri posuzovani MySQL je treba brat v uvahu engene. Mezi MyISAM a InnoDB pripadne Falconem nebo Solidem jsou dost zasadni rozdily. MySQL je pouze obalkou nadkonkretnim engenem. Vlastnosti a kvalita je dana vlastnostmi a kvalitou engine .. vetsina jich dnes ani nepochazi od MySQL. Dnes podstatne dulezitejsi nez SQL92 je SQL2003. MySQL umoznuje psat dle ANSI (ve verzi 5.x). To, ze ma hromadu vlastnich rozsireni, ktere umoznuji psat nestandardne je uz problem programatora a zpetne kompatibility. Bohuzel dost tezko se lze, i v open source, vykaslat na nektery ficury, i kdyz se casem ukaze, ze jejich implementace nebyl ten uplne nejlepsi napad.
Kvalita jakeho kodu? Kazdy se bavite o necem jinem.
Zobecnujete fakt, ktery plati pro PostgreSQL, cimz z tohoto faktu tvorite zcela zamerne neplatne pravidlo, abyste poukazal na to, ze tento fakt nemuze byt pravidlem.
PostgreSQL je starsi, nez MySQL - to znamena V TOMTO KONKRETNIM PRIPADE ze je PostgreSQL odladenejsi, protoze se uziva jako databaze mnohem vice let, nez hracka MySQL a zaroven to je duvodem, proc ma PgSQL vice funkci, tzn. je robustnejsi.
Ke zbytku se vyjadrovat nebudu, zase zobecnujete, jste od reality velice vzdalen. Cim vice budete zobecnovat, tim vetsi *** se z Vas postupne stava.
Ted bych se mel nastvat (nemam rad, kdyz mne nekdo oznacuje ***, a ani se pod to nepodepise) :). Znam Postgres (koneckoncu jsem napsal clanek, pod kterym diskutujem), do Pg jsem prihodil i par patchu, takze tusim jak vypada kod. S kamaradem jsem jednou hackoval i MySQL. Budu mluvit konkretne. V 8.3 doslo ke zmene formatu typu varlena, coz vedlo k modifikaci dost velke casti nizkourovnoveho kodu, tudiz je 8.3 podstatne mene odladena nez napr. 8.2, pokud bych vztahoval odladenost ke stari. Naopak MySQL 5.1 podporuje Solid engine, ktery existuje minimalne od roku 97 .. PostgreSQL je natolik kvalitni databaze, ze snese objektivni diskuzi.
Neni moc kompatibilni se standardem JDBC3 a v nekterych pripadech se holt musi pouzivat workaroundy pro chybejici funkce. Nektere funkce jsou implementovany znacne neefektivne. Pritom JDBC3 neni zadna 'last technology'. Uz dlouhou dobu shanim nekoho, kdo by se nechal najmout na to, aby JDBC driver trochu dal do kupy a porad nic. Ale kdyz dotycna osoba zjisti, co se ma delat tak s tim flakne. Pravda, mohl bych zase postnout offer do postgresql-jobs, ale asi to uz nema cenu.
2. Replikace Slony1
Nestiha vetsi load na serveru, vyzaduje vicemene synchronizovane hodiny serveru VCETNE TIMEZONY!, dochazi cas od casu ke ztrate synchronizace, kdy proste obsah nekterych transakci zmizi ale servery si stale mysli ze jsou syncnuti, skalovatelnost je N*N, pro vice nez par serveru tudiz nepouzitelne, prikaz EXECUTE SCRIPT zejmena jeho obsluha chyb je bastl, nemoznost obnovit replikovanou databazi z backupu (rozhodi se mapovani objektu vazane na OID),
nutnost rucne vytvorit prazdne tabulky na slavech, velka zavislost na RTT,
zadna optimalizace pri provadeni zmen v cilove db, switchovani replikacnich
logu vice nefunguje nez funguje a jsou pouzity jen 2 ja mam naprikad v jednom
logu 80M radek a druhy prazdny. Velky log sejme replikaci protoze slave se uz nikdy nechytne (napr. vyber prvniho radku z 80M replikacniho logu trva cca 3 minuty a servery maji HB 60 sec - vice nastavit nejde)
3. VACUUM FULL
chce to online reorganizaci dat v databazi (Oracle ma, DB2 umi vcetne RAID0 mezi vice tablespaces), a pri indexy nad tabulkami je to velmi velmi pomale. Melo by to automaticky dropnout a pak vytvorit indexy pokud statistika rika ze bude potreba udelat hodne zmen.
4. Zlepsit system alokace diskspace
a) vracet volne misto preferovane ze zacatku tabulky
b) Alokovat diskspace pomoci extentu, misto alokace 8kb bloku to brat rekneme po 50MB (uzivatelem nastavitelne).
Se zamestavanim lidi so by pracovali na PGSQL, Slony1, JDBC to neni moc ruzove. OSS koderi vetsinou chteji delat na projektu ktery zajima je a ne zamestnavatele a krom toho maji znacne prehnane naroky na plat. Par jsem jich kontaktoval a chteli $8-15K nastupni plat.
Nejlepsi vec na PGSQL je ta, ze k tomu dela support Sun, takze je to jedna z mala OSS databazi co se da realne pouzit pro vetsi projekty, kde byl driv Oracle.
PostgreSQL ma daleko do idealu i do dokonceni. Uz ted je ve fronte dost patchu na verzi 8.4. Mne treba dost mrzi chybejici podpora COLLATES, coz vidim asi jako nejvetsi nevyhodu. A je pravda, ze replikace v pg, pri silne zatezi, vede dost k velkemu loadu a pak i k nestabilite systemu.
@1. Drivery nejsou soucasti projektu, coz tedy neomlouva. Zrovna tak jak je nedokonale JDBC je dost omezene i OLEDB. U JDBC bych rekl, ze je problem spis v lidech, u OLEDB jsou problemy v technologii, neb napsat korektni driver zrejme dovedou jen u Microsoftu. V nejlepsim stavu je patrne driver pro .NET.
@2. Teoreticky by se melo objevit slony II. Alespon 8.3 obsahuje nektere patche, ktere SlonyII vyzaduje. Jinak SlonyII je separatni projekt, takze se mozna objevi drive nez za rok. Jednim z cilu 8.4 je prepsani mechanismu LISTEN/NOTIFY, coz je prave to hrdlo, ktere limituje SlonyI. Realne si myslim, ze neni sance, ze by 8.4 obsahovala podporu replikaci. Patrne se bude pokracovat v lepsi podpore prubezneho zalohovani, ale to je vse. Je mozne, ze s necim prijde EnterpriseDB.
@3. Druhy cil 8.4 je nahrada FULL VACUA. Nicmene uz ted by melo dost pomoci HOT updates. Automaticke dropnuti indexu mi prijde jako docela drsna zalezitost. Mozna by stalo za uvahu vytvorit dalsi variantu vacua neco jako VACUUM FULL REINDEX ANALYZE :). V 8.4 by mela obsahovat evidenci stranek obsahujici mrtve zaznamy. Tudiz FULL FACUUM nebude skenovat celou tabulku, ale pouze prislusne stranky. To by melo celou operaci urychlit.
@4. Souvisi s evidenci volnych stranek. Kdyz naalokuji dopredu 500M, musim odpovidajicim zpusobem zvednout FSM. V podstate je to mozne uz ted .. napr. naplnit tabulku milionem zaznamu, dat delete, nechat jeden zaznam a VACUUM. Nesmi se spustit FULL VACUUM. A asi by to slo napsat i cisteji. Ale urcite to neni na poradu dne, pokud to neprijde od EDB a pokud nedokazi prokazatelne prinos. Zatim, bez evidence mrtvych stranek, by predbezna alokace znamena jen zpomaleni VACUUM.
Od toho je open source, ze lidi delaji na tom, co je bavi. Budto delaji zadarmo ale bez zavazku nebo komercne (za standardnich podminek). Za 3K$ mesicne si myslim, ze by se nekdo mel najit (tady nebo na vychod od nas). Kdybych umel javu, tak bych do toho sel sam :).
Sun urcite dela pro PostgreSQL hodne, ale take z toho ma profit. Diky Sunu, resp. vyvojaru z Prazske pobocky, PostgreSQL na Solarisu bezi docela dobre (hlavne je rychle fixovan) a je tu jeden nebo dva experimetalni projekty. Na Solarisu a na Sun serverech se s Postgresem uz ted delaji veci nad kterymi zustava rozum stat. Ostatne o tom byla Joshova prednaska v Praze.
Vsimnete si, kolik ze Softu co dela Sun (vetsina je napsana v Jave) podporuje PGSQL. Mam tim na mysli treba Directory Server, Glassfish aplikacni server, Sun Identity manager, Sun web server, atd.
Odpoved zni: NIC. Podporuje se Oracle, MySQL, DB2.
Protoze je v seznamu i OSS MySQL, tak verte tomu ze kdyby to na PGSQL chodilo, tak by to bylo podporovano taky. PGSQL Sunem podporovan je, ale ne pro tyto produkty.
Ale treba Python driver Psyco pro PGSQL je fakt svely a v PHP s nim taky nejsou problemy. O ODBC driveru bych taktez taktne pomlcel.
diky za spoustu novych informaci, treba o podpore od sunu jsem nevedel.
je docela nemile ze jsou problemy s jdbc ovladacem. pritom to je pro vetsinu uzivatelu asi to nejdulezitejsi, sam zapasim hlavne s jdbc ovladaci oraclu a i pouhe pripojeni k databazi muze byt problem :-)
s tou neefektivou bych cekal ze se da neco udelat, pokud jde pouze o vlastni kod mate mu treba netbeans s opravdu skvelym profilerem. docela by me to i zajimalo.
O neefektivite JDBC driveru jsem nemel na mysli efektivitu na Java urovni t.j. efektivitu parsovani dat ze serveru a tak, tu jsem nemeril. Mel jsem na mysli efektivitu na DB urovni. Tim mam na mysli napriklad neposilat pri zavolani jedne fce driveru db serveru 3 statementy pokud se daji sloucit do jednoho. Protoze autori z nejakeho prapodivneho duvodu pozaduji kompatibilitu s 8 let starou pgsql verzi. Krom toho taky nechapu proc je soucasti stable driveru kod, o kterem se vi, ze nefunguje. Lepsi je ten kod ze stable vetve vyhodit a hazet prislusnych fci Exceptions("Not supported").
Ten driver by se mel procistit. Podporovat stejne jako Sun PGSQL 8.1, 8.2. A zamerit se pouze na JDBC3. Je to ale utopie, to se pokud se nezmeni project leader ktery na vetsinu bugreportu odpovida nemam cas nebo to nekdo neforkne nikdy nestane. Tim chci rict kdyby se ten cas, ktery vynakladaji ti co na jdbc obcas delaji k uceni lidi pouzivat workaroundy, radsi vyuzil pro kodovani vypadalo by to dneska jinak.
Problem je ze ve vetsine OSS projektu jsou developeri zcela mimo realitu. Realita je, ze nejpozivanejsi aplikacni server pro J2EE je jboss/hibernate a kdyz ma hibernate s pgsql problemy, tak misto matlani podpory pro JDBC4 by bylo dobre konecne opravit leta stare bugy. Ale chapu kdyz maji lidi psani JDBC driveru jako konicek, podpora pro JDBC4 je vice sexy.
Kdyz se mne nekdo pta zda PGSQL nebo Oracle pro JBoss odpovidam v kazdem pripade Oracle, PGSQL by sice jako databaze bez problemu stacil, ale ma spatny JDBC driver. Pokud nechcete Oracle dejte tam MySQL.
Tohle už je o pravidelné bušení do lidí, kteří dělají JDBC driver, případně jim sem tam poslat nějaký patch, by si o člověku nemysleli, že je kverulant. Co se týče podpory starých verzí Postgresu, tak svůj podíl viny má RedHat a Debian, kteří za boha nechtěli přejít na 8.x řadu. Jinak by už sedmičková řada dávno odešla do krajiny zapomnění. Jelikož Sun začal s 8.1, tak se nedivím, že podporuje pouze 8.1,8.2. Zkus kontaktovat Zdeňka Kotalu .. ten má u Sunu PostgreSQL - přijde mi, že se s ním dá mluvit,
No ja vidim jedinou realnou sanci na zlepseni situace ohledne JDBC, ze to proste nekdo forkne. Patche nejake jsem jim poslal, ale nic necommitnuli protoze to nechodilo ve starych pgsql verzich, krom toho mne uz nudi poslouchat jejich reci jako je to opensource oprav si to sam. Stavajici team na to fakt nema.
Napriklad zakaznici by mohli bombardovat Sun bug reporty ohledne JDBC v PGSQL a tim padem presvedcit Sun, aby to forknul na java.net. Pote co by se to forklo a vyhazela by se podpora pro stare pgsql verze myslim ze by z toho mohl byt decentni driver tak za 2 mesice, kdyby na tom nekdo delal denne.
hmm kdybych mel alespon tyden abych na tom mohl neco udelat, tak bych to forknul a on by se uz (doufejme) nekdo chytil, idealni by bylo kdyby sun dodal tak jednoho az dva kodery, ten driver neni zase tak velky.
Tedy jeste mne zajima jaky JDBC driver ma ten komercni PGSQL, ten jsem jeste nezkousel.
Plán je to dobrej. EDB nikde se nevyhraňuje tím, že by její JDBC driver byl lepší než standardní. Takže asi tak. Na druhou stranu oni teď musí vycházet zákazníkům vstříc. Je to komerční firma, a každý platící zákazník je pro důležitý.
No ale bylo uz na case, tohleto je pro mne nejlepsi featura z 8.3, hned si jdu stahnout 8.3 a jdu to testit zejmena zda to ma zamykani zaznamu ala Oracle.