Vlákno názorů k článku PostgreSQL 8.3: nejen razantní navýšení výkonu od j. peterka - rad bych se zeptal autora jak realisticky vidi...
-
j. peterka (neregistrovaný)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. -
Maverick (neregistrovaný)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? -
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. -
j.peterka (neregistrovaný)[...] 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.
