From: | Enrico Weigelt <weigelt(at)metux(dot)de> |
---|---|
To: | pgsql-de-allgemein(at)postgresql(dot)org |
Subject: | Re: writable view performance #1 |
Date: | 2006-12-25 02:59:02 |
Message-ID: | 20061225025902.GA23486@nibiru.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-de-allgemein |
* Andreas Kretschmer <akretschmer(at)spamfence(dot)net> schrieb:
> Enrico Weigelt <weigelt(at)metux(dot)de> schrieb:
> > * Die Suchtergebnisse der einzelnen Nutzer (incl. seen-flag,
> ^^^^^
> Hehe ;-)
*lol*
> > * die Table base.platform wird eingebaut (join), auch wenn die daraus
> > entstammenden Felder nicht benutzt werden. Kann das denn nicht
> > wegoptimiert werden ?
>
> Wenn diese Table mit eingebaut wird, dann wird das wohl nötig sein.
> Offensichtlich wird diese irgendwo in Deinen Views mit referenziert.
Im View an sich ja, aber nicht in der konkreten Query.
> > * bei base.platform und base.user werden keine Indices benutzt.
> > Okay, die sind noch sehr klein -> lohnt vielleicht nocht nicht ?
>
> Möglich. Bei kleinen Tabellen ist die Verwendung eines Indexes u.U.
> 'teurer' als der direkte table-scan, weil er mehr Plattenzugriffe
> braucht (erst Index, dann table) und die Table möglicherweise so klein
> ist, daß da ein einzelner Block auf der Spindel ist -> ein einzelner
> Zugriff.
Ja, das dacht ich mir schon. Mal sehen, wie sich das entwickelt,
wenn es ein paar mehr User sind. (darfst Dich gern registrieren ;-))
> > * ich hab auf das seen-Flag (auch in Verbindung mit allerlei anderen
> > hier benutzten Feldern) Indices gesetzt - keiner wird verwendet.
>
> BOOL-Felder und Indexe, naja, solche Felder haben keine hohe
> Selektivität. Näheres würde ein explain analyse verraten.
Das bringt wohl nicht viele Punkte ?
Ich hab unterdessen die Table user_results aufgespaltet - was
früher seen=true hatte, landet jetzt in einer eigenen Table
und wird nur in jene Views eingebaut, die wirklich auch die
ungelesen zeigen sollen.
Schneller ist's dadurch aber auch nicht geworden :(
Die periodischen Sortier-Queries brauchen immernoch ca. 0.7sec
bis 1.2sec je Stk.
> > Hat jemand vielleicht noch ein paar Tips, wo ich noch etwas
> > optimieren könnte ?
>
> - schaue Dir relevante Abfragen mit EXPLAIN ANALYSE an
klar :)
> - Tabellen, die vielen Änderungen (Updates/Deletes) unterliegen
> benötigen öfters mal ein Vacuum
Wie oft ? Gibts da eine Richtschnur ?
BTW: werden eigentlich überflüssige updates (also bei denen
praktisch dieselben Werte wieder geschrieben werden) von postgres
selbst abgefangen oder gibts da jedesmal echte Schreiboperationen ?
> - welche Version von PG?
8.0.8
> - Frohe Weihnachten!
ACK.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Kretschmer | 2006-12-25 17:18:53 | Re: writable view performance #1 |
Previous Message | Andreas Kretschmer | 2006-12-24 09:20:34 | Re: writable view performance #1 |