PostgreSQL a budoucnost

[Ing. Pavel PaJaSoft Janousek]

Karel Zak wrote:
>  Uf.. ted jsem se podival do TODO a u tohodle bodu ("Improve control
>  over user privileges") je me jmeno. To je zajimave, asi jsem do toho
>  moc kecal :-)

	Neco podobne jsem zazil, dobre Ti tak...;-)
BTW Jsi u toho uveden uz dost dlouho, aspon tak 3 tydny, to jsem zjistil
ze replikace je URGENT...;-)

> > >     - jeste lepsi storage manager
> >
> >       Jaka je snaha?
> 
>  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? 

> > >     - 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?

>  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.)

>  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).

>  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
zni zajimave, ostatne Java je jen dalsi jazyk do bohate skaly;-).

>  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...

Horak Daniel wrote:
> >  Co se tyka RAW tak zadne snahy nejsou a asi hned tak nebudou (mizerna
> >  portovatelnost apod.)
> 
> Snahy (vicemene akademicke) byly cca pred rokem, ale nic se
> nerealizovalo, prave z duvodu mizerne portovatelnosti. A je otazkou,
> jake urychleni tim lze docilit.

	Vim, ze RAW devices ala Linux je houby portovatelnost. Urychleni myslim
je nezanedbatelne diky rezii, kterou bezny (vcetne Linuxu) OS venuje
managementu souboru (bufferovani, cache, read ahead apod.) jeho
fyzickemu 'rozprostreni' na HW apod. Pravda, poctive vysledky pro
podporu tohoto tvrzeni nemam, logika veci mi vsak neda...;-)

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------