Re: writable view performance #1

[Andreas Kretschmer <akretschmer(at)spamfence(dot)net>]

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°