optimalizace triggeru (Postgres, ...)

Ing. Pavel PaJaSoft Janousek janousek na fonet.cz
Pátek Prosinec 15 16:23:12 CET 2000


>   Do C to prepisu, v tom bych problem nevidel. Takze vas uz nic jineho
> (po skouknuti triggeru) nenapada co s tim. Abych pravdu rekl, mne nenapada
> vubec nic. Samozrejme indexy na ty tabulky jsou vytvorene a indexuje se
> podle - line, counterstamp, line & counterstamp. Problem je, ze to co
> pet minut bude generovat zhruba tech 1000 grafu z tech vsech udaju
> (peti min, hodinove, denni, mesicni), takze ta databaze bude vcelku zatizena.
>   Koukal sem, ze jste neco do Postgresu delal, nejaka finticka jak to urychlit
> primo v Postgresu asi neni, co?

	Zdravim,

	trosku z uplne jineho soudku... - co nemychat aktualni udaje s tim, co
uz je staticke, tedy namerene hodnoty starsi nez rekneme 1 minuta?

	Chapu, ze jedna tabulka rychle poroste, ale:
1. Kdyz se provedou sumarizace za <od> <do>, muze se tento usek z teto
tabulky smazat
2. U PostgreSQL vacuum uz jde pokud vim delat i za behu => i na disku
bude misto

	Ostatni tabulky porostou, ale jen sumarizacne a v principu nemusi byt
na stejne masine (v pripade, ze zatez je enormni a potrebujete skalovat)
jako tabulka, ktera roste kazdou chvilinku o udaje... Myslim, ze jazyk C
a ECPG (pochopil jsem, ze pouzivate PgSQL) je v tomto pripade vase dobra
zbran (stejne jako C a libpq, kazdemu co ma rad:)).

	Jeste k tem indexum - osobne si myslim, ze v tomto postaveni (ktery
navrhuji) je pro vas podstatnejsi rychlost zapisu do rychle narustajici
tabulky => zadne indexy, protoze ty insert zdrzuji, naopak Vas netrapi,
ze sumarizace <od> <do> nejakeho udaje bude trvat X-krat pomaleji,
protoze se provede jen jednou a vysledek se ulozi do sumarizacni tabulky
(udaj je staticky, nema se jak zmenit). Alespon tak si to predstavuju,
pokud jsem dobre pochopil jde Vam o optimalizaci mereni pretecenych dat
Vasima linkama zakaznikum (BTW jako Vasi zakaznici musim konstatovat, ze
mereni neni uplne presne'-))

	Sam jsem se podobnymi problemy zabyval a myslenek jak navrhovat
skalovatelna reseni je vice... - vcetne napr. takova, aby vstupni data
byla davana ciste do TXT souboru, ktery se napr. pres sit zpristupni a
databaze se z nej teprve tvori off-line (byt s minimalnim zpozdenim) -
toto je velmi robustni reseni (vice pocitacu, vice procesoru, kazdy se
stara o svou cast a v podstate se neperou).

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Anenska 11, 602 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
-----------------------------------------------------------------------


Další informace o konferenci Test