PostgreSQL a budoucnost

[Karel Zak]

On Wed, Nov 14, 2001 at 03:42:52PM +0100, Ing. Pavel PaJaSoft Janousek wrote:
> >  Uplne todle nesleduji, ale je tam co zlepsivat ohledne nutnosti co
> >  nejvice potlacit nutnost pouzivat VACUUM. Dale pak nejake finalni
> 
> 	Tady bych se zastavil, je to normalni?:
> 
> 1. Mam aplikaci, ktera s DB (2 tabulky) dela tuto vec (urcita specificka
> statistika):
> a) cte z tabulky A
> b) neco udela a zapise (pouze INSERT) do tabulky B
> c) dotazuje se do tabulek A i B
> 
> 	Nic jineho jako update, delete se nikdy nedeje...
> 
> 	Co mne zarazi je to, ze po VACUUM se sice obnovi obcas cast prostoru
> (nekdy i nekolim desitek MB) - kdo a proc ho alokoval? Co je vsak na
> provaz je fakt, ze na tabulku B jsou vytvoreny nejake zakladni indexy
> (skutecne jen create index <name> on <table> (<col>)). Velikost techto
> indexu roste naprosto neumerne vudci velikosti jak tabulky ze ktere je
> tvorena, jednak po VACUUM se nestane nic, ale co je nejhorsiho, pak po
> drop index, create index (ten samy, ale je logicke, ze s vice daty) ma
> za vysledek ze soubor (jedna se o 7.0, tudiz se to jeste dal dobre
> sledovat:->) s indexem je nekdy i o 2 rady!!! mensi nez prubezne
> vytvareny index... - proc? 

 Nevim. Asi to souvisi s tim, ze soubory umi jen rust. Zmensovat je uci 
 jen VACUUM. 
 
> > > >     - urychleni startu backendu (poz. MySQL ma jeden z nejrychlejsich
> > > >       connectu coz je treba u prumernych zpusoby implementaci webu
> > > >       skvela vec)
> > >
> > >       Tiny PostgreSQL uz nebude PostgreSQL, ale optimalizaci se nebranim.
> > 
> >  O to nejde. Jde o pre-forked backend. Tedy neco jako u apache kde
> >  hned po startu vznikne nekolik serveru a pri connectu klienta se
> >  netravi cas forkem a startem serveru. Dost by to pomohlo vecem jako
> >  je web.
> 
> 	Tomu silne rozumim, resp. chapu moznosti i vyhody/nevyhody - mam asi
> logicky dotaz, proc uz to tam neni ci proc se bude vymyslet Amerika -
> myslim, ze toto rozkladani napr. v Apache (i ve verzi 1.3.) je dost
> optimalni oproti normalnimu daemonizovany - konexe per proces, licence
> snad pouziti nebrani, ne?

 Myslim, ze zde ale neni problem ve vymysleni jako v tom najit cas sednou 
 a napsat :-) Ono to pochopitelne neni zase tak uplne jednoduche. Vice
 viz. archiv pg-hackers.

> >  Nemyslim, ze zrovan Tom Lane (PostgreSQL neni projektem jednoho boha
> >  jako to je treba "nekde" jinde:-) by resil veci okolo storage managmentu.
> 
> 	'-) nekomentuji, nemam v umyslu vyvolavat flamesy... K tomu Tomovi - v
> aktualnim TODO je dost veci, ktere souvisi se storage managementem a ma
> to Tom Lane zabookovane (napr. re-usage row without vacuum apod.)

 To ano, ale transakce, WAL a storage managment pisou jini. Tom to pak 
 vetsinou dodela :-)

> >  Dalsi vec, ktera treba mne znacne stve (nekdy i ser..) je hlaseni
> >  erroru. Pokud ma byt PostgreSQL pouzitelny v nejakych solidnich
> >  oblastech je nutne, aby existovaly kody chyb a aplikace mohla dle
> >  kodu neco udelat. Dnes vetsinou jen trapne vypise string errorove
> >  hlasky.
> 
> 	Pouzivej JDBC a jsi odstinen, ono je to i trochu problem, protoze zadny
> standard aspon zakladnich fatalnich chyb neexistuje (nevim o nem).

 JDBC pokud napriklad porusim referencni integritu tak mi rekne co se
 stalo a jak mohu poslat na GUI hlasku "vole usere co tam strkas za
 data"? To by znamenalo, ze JDBC parsuje errory protoze, RI trigery
 proste nic jineho nez tu error hlasku (string) do sveta neposilaji.

> >  Dale pak treba LOCALE-per column, UPDATE na view, pouzivat indexy u
> >  max(), min() (viz rychlost tohodle u MySQL), psani serverovych
> >  funkci v Jave.
> 
> 	Ono by casto staci LOCALE per table...;-) Psani serverovych veci v Jave

 Jde o nutnost byt schopen indexovat a porovnavat ruzne soupce.

> zni zajimave, ostatne Java je jen dalsi jazyk do bohate skaly;-).

 Soucasne zavery jsou ze to neni tak snadne. Rad bych take nejake
 reseni videl, protoze by to pak slo pouzit i u Mape :-)

> >  Atd.. atd. TODO ma 15 stranek :-)
> > 
> >     http://developer.postgresql.org/todo.php
> 
> 	Ano, jeho velikost je obdivuhodna (ostatne je to jen dobre), problem je
> ale v tom, ze krome vystizneho URGENT nemam potuchy (a popis jsem
> nenasel) jakou maji prioritu ostatni TODO polozky...

 Hmm.. na zacaktu kazdeho vyvojoveho cyklu jsou ty priority recene a
 tak nejak "duch" konference ten smer ukazuje :-) Pravda mohlo by to
 byt lepsi, ale mohl by ten projekt management byt i horsi (priklad
 zname:-).

        Karel
 
-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz