writable view performance #1

From: Enrico Weigelt <weigelt(at)metux(dot)de>
To: pgsql-de-allgemein <pgsql-de-allgemein(at)postgresql(dot)org>
Subject: writable view performance #1
Date: 2006-12-23 19:03:02
Message-ID: 20061223190302.GA28936@nibiru.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein


Hallo Leute,

ich bin gerade dabei, eine Anwendung (ein Auktions-Crawler,
siehe http://auctionwatch.metux.de/) ein wenig zu optimieren.

Zum besseren Verständnis hol ich erstmal etwas weitera aus:

* Aus Nutzer-Sicht erlaubt die Anwendung erstmal, bestimmte
Feeds von ebay (spaeter auch andere) zu abonieren. Es landen
dann immer die jeweils neuen Artikel in der incoming-queue.
Als gelesen markierte Artikel werden dem Nutzer nicht mehr
angezeigt, bleiben aber in der DB (uA. um nicht nach dem
nächsten scan wieder zu erscheinen).
* Für jeden Nutzer können Filter-Regeln gesetzt werden
(änhlich procmail ;-)), nach denen Artikel von einer
Queue irgentwo anders hin umsortiert werden können.
(zB. kann man so anhand Thumbnail-md5 und/oder Preis
wiederkehrende zu teure oder uninteressante Artikel gleich
wegsortieren :))
* Die Artikel werden zunächst in der Tabelle base.articles
gespeichert. Dort wird das Auktionshaus via ID zur Tabelle
base.platform referenziert.
* Die Suchtergebnisse der einzelnen Nutzer (incl. seen-flag,
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 ?
* bei base.platform und base.user werden keine Indices benutzt.
Okay, die sind noch sehr klein -> lohnt vielleicht nocht nicht ?
* ich hab auf das seen-Flag (auch in Verbindung mit allerlei anderen
hier benutzten Feldern) Indices gesetzt - keiner wird verwendet.
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 ?

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

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Andreas Kretschmer 2006-12-24 09:20:34 Re: writable view performance #1
Previous Message Andreas Kretschmer 2006-12-19 20:58:50 Re: Re: Verwendung von numerischen Field-Bezeichnern