Re: writable view performance #1

From: Andreas Kretschmer <akretschmer(at)spamfence(dot)net>
To: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: writable view performance #1
Date: 2006-12-24 09:20:34
Message-ID: 20061224092034.GA7409@KanotixBox
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Enrico Weigelt <weigelt(at)metux(dot)de> schrieb:
> * Die Suchtergebnisse der einzelnen Nutzer (incl. seen-flag,
^^^^^
Hehe ;-)

> queue, ...) stehen in base.user_results - dort werden sowohl
> Nutzer als auch Artikel via ID nach base.users bzw. base.articles
> referenziert.
> * Der Crawler greift über (zT. schreibbare) Views crawler.* zu.
> Er wirft die neuen Suchergebnisse nach crawler.user_results,
> wo username und platform mit dem Namen dargestellt werden.
> * Der Filter-Prozess arbeitet sukzessive die Nutzer bzw deren
> Regeln durch und löst Queries der Form aus:
>
> UPDATE crawler.user_results
> SET queue='{ ... Ziel-Queue ...}'
> WHERE
> NOT seen AND
> queue = '{ ... Quell-Queue ...}' AND
> username = '{ ... Nutzer ... }' AND
> { ... Filter ... }
> ;
>
> Lt. EXPLAIN ANALYZE werden da einige (IMHO) wunderliche Dinge getan, zB.
>
> * 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.

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

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

> Eigentlich hatte ich gehofft, daß wenigstens ein Index schonmal
> zum rausfischen der eigentlich interessanten (NOT seen) Rows
> benutzt werden könnte, und nicht über die stetig wachsende
> Masse der seen-markierten gescannt werden muß.
>
>
> Hat jemand vielleicht noch ein paar Tips, wo ich noch etwas
> optimieren könnte ?

- schaue Dir relevante Abfragen mit EXPLAIN ANALYSE an
- Tabellen, die vielen Änderungen (Updates/Deletes) unterliegen
benötigen öfters mal ein Vacuum
- welche Version von PG?
- Frohe Weihnachten!

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Enrico Weigelt 2006-12-25 02:59:02 Re: writable view performance #1
Previous Message Enrico Weigelt 2006-12-23 19:03:02 writable view performance #1