| Lists: | pgsql-de-allgemein |
|---|
| From: | Tobias Bußmann <e(dot)t(dot)bussmann(at)ing(dot)twinwave(dot)net> |
|---|---|
| To: | "Postgres-D ML" <pgusers(at)postgres(dot)de>, <pgsql-de-allgemein(at)postgresql(dot)org> |
| Subject: | Cached views |
| Date: | 2006-01-13 17:57:19 |
| Message-ID: | 036101c6186a$cf93877083fea9@LaptopTB |
| Views: | Raw Message | Postgr토토QL : | Download mbox | Resend email |
| Lists: | pgsql-de-allgemein |
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, aber
sicherlich nicht soweit dass sich damit adäquate Zugriffszeiten realisieren
ließen). Diese bilden die Grundlage für eine Vielzahl weiterer Queries -
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äufig 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 gesagt
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 Verwaltung
der Temp. Tabellen und zugehörigen Queries, periodisches Neuerzeugen dieser
usw.
hat jemand Erfahrung mit sowas?
lg
Tobias
| From: | Joachim Wieland <joe(at)mcknight(dot)de> |
|---|---|
| To: | Tobias Bußmann <e(dot)t(dot)bussmann(at)ing(dot)twinwave(dot)net> |
| Cc: | Postgres-D ML <pgusers(at)postgres(dot)de>, pgsql-de-allgemein(at)postgresql(dot)org |
| Subject: | Re: Cached views |
| Date: | 2006-01-13 18:45:43 |
| Message-ID: | 20060113184543.GA5917@mcknight.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-de-allgemein |
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 Verwaltung
> der Temp. Tabellen und zugehörigen Queries, periodisches Neuerzeugen dieser
> 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/matviews.html
Joachim
| From: | "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com> |
|---|---|
| To: | Postgres-D ML <pgusers(at)postgres(dot)de>, pgsql-de-allgemein(at)postgresql(dot)org |
| Subject: | Re: Cached views |
| Date: | 2006-01-13 19:00:22 |
| Message-ID: | 20060113190022.GA24697@webserv.wug-glas.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-de-allgemein |
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 zum
> Ausführen brauchen (könnte sicherlich noch etwas optimiert werden, aber
> sicherlich nicht soweit dass sich damit adäquate Zugriffszeiten realisieren
> ließen). Diese bilden die Grundlage für eine Vielzahl weiterer Queries -
> 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.
Vielleicht hilft:
http://www.google.com/custom?hl=de&ie=ISO-8859-1&cof=AWFID%3Aab5bba380ded89ff%3BL%3Ahttp%3A%2F%2Fwww.varlena.com%2FImages%2Fvlogo3.jpg%3BLH%3A46%3BLW%3A76%3BBGC%3A%23FFFFDD%3BT%3A%23000000%3BLC%3A%23005500%3BVLC%3A%23445500%3BALC%3A%23445500%3BGALT%3A%23008000%3BGFNT%3A%23000000%3BGIMP%3A%23000000%3BDIV%3A%23005500%3BLBGC%3A%23FFFFDD%3BAH%3Aleft%3BS%3Ahttp%3A%2F%2Fwww.varlena.com%3B&domains=varlena.com&q=materialized+view&btnG=Suche&sitesearch=varlena.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 gesagt
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 gefü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 anfragen, ob
> es irgendwo ein Projekt gibt (auf pgFoundry hab ich auf die Schnelle nix
> gefunden) das sich mit dieser Problemstellung beschäftigt. Also Verwaltung
> der Temp. Tabellen und zugehörigen Queries, periodisches Neuerzeugen dieser
> usw.
Ich erzeuge @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
=== Schollglas Unternehmensgruppe ===
| From: | Axel Straschil <axel(at)straschil(dot)com> |
|---|---|
| To: | pgsql-de-allgemein(at)postgresql(dot)org |
| Subject: | Re: Cached views |
| Date: | 2006-01-14 07:33:09 |
| Message-ID: | slrndsha9l.j0f.axel@m2.sine |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | Postg토토 커뮤니티SQL : Postg토토 |
Hallo!
> ließen). Diese bilden die Grundlage für eine Vielzahl weiterer Queries -
[...]
> 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.
