Hallo zusammen,
ich habe hier einige Views die recht komplex sind und mehrere Minuten zum
Ausführen brauchen (könnte sicherlich noch etwas optimiert werden, ab=
er
sicherlich nicht soweit dass sich damit adäquate Zugriffszeiten realisi=
eren
ließen). Diese bilden die Grundlage für eine Vielzahl weiterer Querie=
s -
teilweise über eine PHP Oberfläche. Diese jedesmal ganz auszuführen=
ist also
nicht praktikabel, da man mit der Anwendung so quasi nicht arbeiten kann.
Zum Glück ändern sich die zu Grunde liegenden Daten nicht allzuhäuf=
ig so
dass es durchaus ausreichen würde auf gecachte Ergebnisse der Querys
zuzugreifen. Gibt es dazu irgendwie eine eingebaute Möglichkeit? Auch w=
äre
ein Index auf diesen Daten nicht schlecht (da auf diesen Queries wie gesa=
gt
einige weitere Queries beruhen). Ich denke die einzige Möglichkeit fü=
hrt
irgendwie über (temporäre?) Tabellen die mit den Query-Resultaten gef=
üllt
werden..
Da ich das Rad aber ungern neu erfinden möchte, wollte ich mal anfragen=
, ob
es irgendwo ein Projekt gibt (auf pgFoundry hab ich auf die Schnelle nix
gefunden) das sich mit dieser Problemstellung beschäftigt. Also Verwalt=
ung
der Temp. Tabellen und zugehörigen Queries, periodisches Neuerzeugen di=
eser
usw.

hat jemand Erfahrung mit sowas?

lg
Tobias


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

Hallo,

On Fri, Jan 13, 2006 at 06:57:19PM +0100, Tobias Bußmann wrote:
> Da ich das Rad aber ungern neu erfinden möchte, wollte ich mal anfragen=
, ob
> es irgendwo ein Projekt gibt (auf pgFoundry hab ich auf die Schnelle nix
> gefunden) das sich mit dieser Problemstellung beschäftigt. Also Verwalt=
ung
> der Temp. Tabellen und zugehörigen Queries, periodisches Neuerzeugen di=
eser
> usw.

Das hört sich nach Materialized Views an. Von Haus aus gibt es bei pgsql
dazu nichts, aber man kann sich was basteln.

Auf techdocs findet sich dazu ein Link, er hierhin führt:

http://jonathangardner.net/PostgreSQL/materialized_views/mat views.html


Joachim

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

am 13.01.2006, um 18:57:19 +0100 mailte Tobias Bußmann folgendes:
> Hallo zusammen,
> ich habe hier einige Views die recht komplex sind und mehrere Minuten z=
um
> Ausführen brauchen (könnte sicherlich noch etwas optimiert werden, =
aber
> sicherlich nicht soweit dass sich damit adäquate Zugriffszeiten reali=
sieren
> ließen). Diese bilden die Grundlage für eine Vielzahl weiterer Quer=
ies -
> teilweise über eine PHP Oberfläche. Diese jedesmal ganz auszuführ=
en ist also
> nicht praktikabel, da man mit der Anwendung so quasi nicht arbeiten kan=
n.

Vielleicht hilft:
http://www.google.com/custom?hl=3Dde&ie=3DISO-8859-1&cof=3DA WFID%3Aab5bba=
380ded89ff%3BL%3Ahttp%3A%2F%2Fwww.varlena.com%2FImages%2Fvlo go3.jpg%3BLH%=
3A46%3BLW%3A76%3BBGC%3A%23FFFFDD%3BT%3A%23000000%3BLC%3A%230 05500%3BVLC%3=
A%23445500%3BALC%3A%23445500%3BGALT%3A%23008000%3BGFNT%3A%23 000000%3BGIMP=
%3A%23000000%3BDIV%3A%23005500%3BLBGC%3A%23FFFFDD%3BAH%3Alef t%3BS%3Ahttp%=
3A%2F%2Fwww.varlena.com%3B&domains=3Dvarlena.com&q=3Dmateria lized+view&bt=
nG=3DSuche&sitesearch=3Dvarlena.com
insbesondere
http://www.varlena.com/varlena/GeneralBits/64.php


> zuzugreifen. Gibt es dazu irgendwie eine eingebaute Möglichkeit? Auch=
wäre
> ein Index auf diesen Daten nicht schlecht (da auf diesen Queries wie ge=
sagt

Uhm. Mach einfach mal ein 'explain analyse' auf die der View
zugrundeliegende Abfrage.


> einige weitere Queries beruhen). Ich denke die einzige Möglichkeit fü=
hrt
> irgendwie über (temporäre?) Tabellen die mit den Query-Resultaten g=
efüllt
> werden..

*Vermutlich* hast Du keine/falsche Indexe. 'explain analyse' hilft, dies
zu ergründen.


> Da ich das Rad aber ungern neu erfinden möchte, wollte ich mal anfrag=
en, ob
> es irgendwo ein Projekt gibt (auf pgFoundry hab ich auf die Schnelle ni=
x
> gefunden) das sich mit dieser Problemstellung beschäftigt. Also Verwa=
ltung
> der Temp. Tabellen und zugehörigen Queries, periodisches Neuerzeugen =
dieser
> usw.

Ich erzeuge [at] work via CRON auch Views, die die Daten der letzten N Tage
beinhalten, es geht hier u.a. um BDE-Meldungen. Dies mache ich aber eher
weniger wegen Performance (hilft ja auch nicht, ein View ist ja ein
SELECT), sondern wegens Bequemlichkeit. Im View sind dann halt Dinge
berechnet, die die dummen Controllnixen sonst mit ihrem Excel-Shit nicht
hinbekommen würden...


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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Hallo!

> ließen). Diese bilden die Grundlage für eine Vielzahl weiterer Quer=
ies -
[...]
> dass es durchaus ausreichen würde auf gecachte Ergebnisse der Querys
> zuzugreifen. Gibt es dazu irgendwie eine eingebaute Möglichkeit?

Schuss ins blaue:
Kann man abschaetzen ob die lange Ausfuehrungszeit in der Koplexitaet
der query liegt (Berechnungen) oder an einer hohen Datenmenge (scan)
liegt?
Wenn zweiters, kann man bei der Meta-Query ev. noch selectierte felder
streichen? Also so umschreiben, dass die meta-query nur keys selectiert,
und dann die anderen queries auf diesen keys joinen, um PG mehr speicher
zu überlassen?

Lg,
AXEL.


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