optimalizace triggeru (Postgres, ...)

[Karel Zak]

On Fri, 15 Dec 2000, Robert Vojta wrote:

> #   No, ja se na to podivam, kazdopadne vyzkousim co to udela s rychlosti, atd.
> # kdyz ty data prenesu do duplikovanych tabulek (statickych) v kterych bude
> # provaden maximalne insert ci delete pozdejsich udaju.
> 
>   Otazka z druhe strany, co je rychlejsi:
> 
>   - nechat to delat triggery

 celkovy cas = trigger + operace (update/insert/delete) 

>   - poustet z cronu program (C & libpq), ktery to bude vsechno delat?

 celkovy cas = BE<->FE + prace FE (ale pro 'x' radek)

 IMHO to je uplne spatna otazka:-) 

	1/	Je-li treba mit ta data ihned tak trigger 
		=> pomalejsi insert
		=> bude se to provadet v kazdem BE (backend)

	2/	Je mozne to delat po castech (po urcite dobe)
		=> nebude tim ovliveno vkladani dat
		=> pripadna sumarizace dat bude provadena *jednim* BE


 IMHO nejrychlejsi mozna varianta - pokud vam dostacuje moznost '2/'
- napsat funkci pro PostgreSQL, ktera bude vykonavat tu sumarizaci
*uvnitr PG* a tuto funkci volat z nejake query

	SELECT moje_sumarizace_dat();

 tim se vyhnete prenosu dat na klienta a nazpet. 

					Karel