Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: writable view performance #1



* 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/
---------------------------------------------------------------------



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group