[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FYI] ATOM ./. RSS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
- -- Kristian Köhntopp <kris@koehntopp.de> wrote:
> http://www.usemod.com/cgi-bin/mb.pl?GroupLens,
> http://citeseer.nj.nec.com/resnick94grouplens.html
ah, war mir nicht bekannt!
> Hat sich wegen mangelnder Unterstützung in den Clients niemals richtig
> durchgesetzt.
tja, schade eigentlich.
Wahrscheinlich mal wieder eine Variante des Henne-Ei-Problems.
> Bäume in SQL _sind_ ekelig,
ich weiss! :)
Und auch die Celko'sche Methode fand ich nicht sooo prickelnd, da langsam
beim Einfügen.
> http://blog.koehntopp.de/archives/158_Baeume_in_SQL.html.
ah, Deine Trees sind ähnlich wie mein "GTree" (G für Genealogical). Der
Unterschied ist im Wesentlichen nur, dass ich keine Trennzeichen
(wahrscheinlich bei Dir auch nur zur Illustration) und keinen Text sondern
einen Binärstring nehme (Postgres' bytea Datentyp; streng genommen derzeit
noch einen base255 codierten Text-String, da bis 7.4.1 bei bytea der Index
nicht immer zum Suchen genommen wurde).
Die ersten beiden Elemente haben drei Byte, alle weiteren zwei; lässt sich
aber durch Konstanten anpassen ;)
Für die meisten Fälle hat man damit aber ausgesorgt: 16,7 Millionen (die
ersten beiden Ebenen) bzw. 65536 direkte Kinder in einem Tree reichen
meist, und wenn nicht habe ich eher ein Plattenplatz-Problem, kann es ja
aber auf 4 bytes (4 Mrd Childs pro Parent) erweitern.
> Der im Artikel erwähnte Kollege fällt nun ganz entschieden nicht in die
> Kategorie Script-Kiddie. Es ist einfach so, daß solche Optimierungen an
> bestehenden Datenbankbäumen haarig sind.
an bestehenden was "live" zu optimieren, das ist sowieso immer so eine
Sache -- wenn nicht gerade jemand vergass Indexe zu setzen :)
> Aber vom Minuten in den
> Sekundenbereich zu kommen bzw. in einem Fall von 23 Sekunden auf unter
> 200ms, das ist schon fein. :)
:-)
odem=> SELECT COUNT(*) FROM forum_gtree;
count
- -------
7452
(1 row)
odem=> EXPLAIN ANALYZE
SELECT author, title, tid
FROM forum_get_data
WHERE gid LIKE '%'
ORDER BY rgid;
[... QUERY PLAN snipped ...]
Total runtime: 203.19 msec
forum_get_data ist ein View, der die Tree- und Daten-Tabelle joint.
Hmmm, und dann noch den Index auf rgid sowie den Primary Key der
Daten-Tabelle clustern, das bringt nochmal ca. 15 Millisekunden.
(gid ist der Pfad (Genealogical ID), rgid ist nochmal ein Rückwärts-GID zum
besseren Sortieren für Foren)
Ich dachte erst: nunja, bei flachen Trees und wenigen Daten ist das ja auch
nicht so schwer, und hab das dann mal mit sehr tiefen (mehrere tausend
Kinder und Kindeskinder) und breiten Trees getestet. Selbst wenn ein Pfad
1000 Zeichen lang ist und sehr viele Elemente drinne stehen geht das alles
noch genauso fix wie vorher. Nungut, irgendwann geht der Cache aus ;)
Probleme macht die Methode nur, wenn man vor einem Child häufig neues
einfügen muss, dann sind viele Updates (bzw. ein großer bzw. entsprechende
Trigger) nötig. Das ist dumm, kann man aber vermindern, indem Lücken
gelassen und später gefüllt werden ...
Ciao
Alvar
- --
** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/
** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html
** ODEM.org-Tour: http://tour.odem.org/
** Informationsgesellschaft: http://www.wsis-koordinierungskreis.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFALM7uOndlH63J86wRAkSSAKC0gFn854nrw4c7+TYjyvoca2GUMACg0KT8
pvVVNmc7bDKfgxToHOysQV8=
=Igon
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: debate-unsubscribe@lists.fitug.de
For additional commands, e-mail: debate-help@lists.fitug.de