Re: writable view performance #1

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

In response to

Responses

Browse pgsql-de-allgemein by date

  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