Hallo Zusammen,

keine Ahnung ob mein Posting von gestern (Betr: cached views?) hier noch
einmal auftaucht. Ich hatte folgendes geschrieben:

"Ich habe Hier in meiner DB einige Views, die bei der Abfrage recht viel Ze=
it
benötigen.
Wenn ich jetzt sehr häufig auf diese Views zugreife multipliziert sich di=
e
Zeit zu enormen Größen.
Dabei ändert sich die Views _in der Regel_ nicht, da sich die zugrundeleg=
enden
Tabellen selten ändern.

Ich habe bissher nicht mit Triggern gearbeitet, aber ich könnte mir folge=
ndes
vorstellen:

Ich habe anstelle der View eine Tabelle (Folgetabelle), die bei jedem lesen=
den
Zugriff zunächst prüft, ob sich die Grundlegende Tabellen gändert hab=
en. Wenn
ja, dann erstelle diese Folgetabelle neu.

Kann man so etwas mit Triggern machen? Ist die Abfrage "ist die letzte
=C4nderung von Tabelle x älter als die letzte =C4nderung von Tabelle y" =
möglich
und schnell. Muß ich dann in den Grundlegenden Tabellen (wieder mit Trigg=
ern)
Zeitstempel setzen ? Oder geschieht das im Hintergrund sowieso?

Oder sollte ich das ganz anders angehen?"

Inzwischen habe ich das richtige Stichwort fuer google gefunden: Materializ=
ed
Views. Jonathan Gardner hat hier schon einiges getan und beschrieben.

Seine Loesung ist aber nicht 100% passend fuer mich.
Er will Materialized Views partiell aktualisieren immer wenn sich grundlege=
nde
Tabellen aendern. Ich moechte Sie komplett aktualisieren, bevor gelesen wir=
d.
Aber nur, wenn sich seit dem vorhergendem lesenden Zugriff die grundlegende=
n
Tabellen gaendert haben. Das diese Matviews dann keine gute constraints
liefern koennen ist ein Einschraenkung, mit der ich leben kann.

Ich will das Rad nicht neu erfinden oder in eine Sackgasse laufen.
Hat jemand eine Idee fuer mich.

Danke,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

am 22.06.2006, um 14:30:12 +0200 mailte Andreas Seik folgendes:
> Dabei ändert sich die Views _in der Regel_ nicht, da sich die zugrund=
elegenden
> Tabellen selten ändern.
>
> Ich habe bissher nicht mit Triggern gearbeitet, aber ich könnte mir f=
olgendes
> vorstellen:
>
> Ich habe anstelle der View eine Tabelle (Folgetabelle), die bei jedem l=
esenden
> Zugriff zunächst prüft, ob sich die Grundlegende Tabellen gändert=
haben. Wenn
> ja, dann erstelle diese Folgetabelle neu.

Es gibt IIRC leider keine Trigger auf SELECT.


> Kann man so etwas mit Triggern machen? Ist die Abfrage "ist die letzte

Du könntest mittels Trigger dir einen Zeitstempel merken, wenn Du die
Basistabelle änderst.

Dann schreibst Du Dir eine SRF, die:

- prüft, ob Zeitstempel existiert.
Falls ja: Nachfolgetabelle erstellen, Zeitstempel löschen
- Nachfolgetabelle ausgeben

>
> Ich will das Rad nicht neu erfinden oder in eine Sackgasse laufen.

Klar, ist doch okay.


> Hat jemand eine Idee fuer mich.

Meine nannte ich. Ob das gut & richtig ist oder es möglicherweise
bessere Lösungen gibt, weiß ich nicht.
Vielleicht kannst Du auch das SELECT, was den View liefert, optimieren.
Aber ich gehe davon aus, das EXPLAIN Dir schon bekannt ist.


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

> am 22.06.2006, um 14:30:12 +0200 mailte Andreas Seik folgendes:
> > Dabei ändert sich die Views _in der Regel_ nicht, da sich die
> > zugrundelegenden Tabellen selten ändern.
> >
> > Ich habe bissher nicht mit Triggern gearbeitet, aber ich könnte mir=

> > folgendes
> > vorstellen:
> >
> > Ich habe anstelle der View eine Tabelle (Folgetabelle), die
> bei jedem
> > lesenden Zugriff zunächst prüft, ob sich die Grundlegende Tabellen=

> > gändert haben. Wenn ja, dann erstelle diese Folgetabelle neu.
>
> Es gibt IIRC leider keine Trigger auf SELECT.

aber rules koennen das doch. war das nicht so, das man aktualisierbare views
mittels
rules erzeugen kann? hilft das hier nicht auch? nur so ein hinweis, bin mir
nicht sicher
ob es in diesem fall passt, ich weis nur sind schon eine feine sache! ;)


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

am 22.06.2006, um 15:14:26 +0200 mailte rene hankel folgendes:
>
>
> > am 22.06.2006, um 14:30:12 +0200 mailte Andreas Seik folgendes:
> > > Dabei ändert sich die Views _in der Regel_ nicht, da sich die
> > > zugrundelegenden Tabellen selten ändern.
> > >
> > > Ich habe bissher nicht mit Triggern gearbeitet, aber ich könnte m=
ir
> > > folgendes
> > > vorstellen:
> > >
> > > Ich habe anstelle der View eine Tabelle (Folgetabelle), die
> > bei jedem
> > > lesenden Zugriff zunächst prüft, ob sich die Grundlegende Tabel=
len
> > > gändert haben. Wenn ja, dann erstelle diese Folgetabelle neu.
> >
> > Es gibt IIRC leider keine Trigger auf SELECT.
>
> aber rules koennen das doch. war das nicht so, das man aktualisierbare =
views
> mittels
> rules erzeugen kann? hilft das hier nicht auch? nur so ein hinweis, bin=
mir
> nicht sicher
> ob es in diesem fall passt, ich weis nur sind schon eine feine sache! ;=
)

Ja. Aber ging ja wohl auch darum, daß das den VIEW erstellende SELECT
langsam ist und nach einer _schnellen_ Lösung gesucht wurde.

Vielleicht meldet sich ja noch psoo, und vielleicht kommen seine
'updateable views' noch in 8.2 rein ;-)

Wie gesagt, der Fragesteller will ja den SELECT auf die Basetable nur
ausgeführt haben, wenn sich diese geändert hat, ansonsten reicht die
wiederholte Ausgabe einer bereits berechneten Ergebnistabelle. Eine via
TRIGGER ausgelöste permanet geführte Ergebnistabelle wäre ja vielle=
icht
auch nicht so toll, weil dann alle INSERT/UPDATE/DELETE auf diese lahm
werden würden. Daher mein Lösungsvorschlag.


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"A. Kretschmer" wrote:

> Meine nannte ich. Ob das gut & richtig ist oder es möglicherweise
> bessere Lösungen gibt, weiß ich nicht.

Der Trigger fuer den Zeitstempel waere auch mein Favorit gewesen:
Einfach, unkompliziert, eindeutig! und ressourcenschonend,

Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are =
!
------------------------------------------------------------ -------------=
-

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Hallo,

Am Donnerstag, 22. Juni 2006 15:02 schrieb A. Kretschmer:
> am 22.06.2006, um 14:30:12 +0200 mailte Andreas Seik folgendes:
> > Dabei ändert sich die Views _in der Regel_ nicht, da sich die
> > zugrundelegenden Tabellen selten ändern.
> >
> > Ich habe bissher nicht mit Triggern gearbeitet, aber ich könnte mir
> > folgendes vorstellen:
> >
> > Ich habe anstelle der View eine Tabelle (Folgetabelle), die bei jedem
> > lesenden Zugriff zunächst prüft, ob sich die Grundlegende Tabellen
> > gändert haben. Wenn ja, dann erstelle diese Folgetabelle neu.
>
> Es gibt IIRC leider keine Trigger auf SELECT.
Aber man könnte einen Trigger auf ein INSERT / UPDATE ansetzen, wenn eine=
der
zugrunde liegenden Tabellen geändert werden. Also nicht erst dann, wenn d=
er
View gelesen werden soll.

Grüße aus Hamburg
Thorsten

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Am Donnerstag, 22. Juni 2006 15:38 schrieb A. Kretschmer:
> am 22.06.2006, um 15:14:26 +0200 mailte rene hankel folgendes:
> > > am 22.06.2006, um 14:30:12 +0200 mailte Andreas Seik folgendes:
....
> > > >bei jedem
> > > > lesenden Zugriff zunächst prüft, ob sich die Grundlegende Tabel=
len
> > > > gändert haben. Wenn ja, dann erstelle diese Folgetabelle neu.
> > >
> > > Es gibt IIRC leider keine Trigger auf SELECT.
....
> > aber rules koennen das doch. war das nicht so, das man aktualisierbare
....
> Ja. Aber ging ja wohl auch darum, daß das den VIEW erstellende SELECT
> langsam ist und nach einer _schnellen_ Lösung gesucht wurde.
>
> Vielleicht meldet sich ja noch psoo, und vielleicht kommen seine
> 'updateable views' noch in 8.2 rein ;-)
>
> Wie gesagt, der Fragesteller will ja den SELECT auf die Basetable nur
> ausgeführt haben, wenn sich diese geändert hat, ansonsten reicht die
> wiederholte Ausgabe einer bereits berechneten Ergebnistabelle. Eine via
> TRIGGER ausgelöste permanet geführte Ergebnistabelle wäre ja vielle=
icht
> auch nicht so toll, weil dann alle INSERT/UPDATE/DELETE auf diese lahm
> werden würden. Daher mein Lösungsvorschlag.

Hallo Andreas und Rene,
so wie ich das sehe, habt Ihr mich beide genau verstanden, und eure Vorschl=
äge
scheinen beide gut zu sein. Ich werde das so versuchen.
Nur das ich Rene offensichtliche anders verstehe als Andreas.
Ich danke Rene schlägt vor (da Trigger (Danke Andreas für den Hinweis) =
für
select nicht vorgesehen sind) statt dessen rules zu nehmen (Anstelle der SR=
F
von Andreas).
Rules in update und insert wären tatsächlich sehr schlecht in meinen Fa=
ll,
aber ich habe Rene so nicht verstanden.

Danke Euch beiden.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq