On Tue, Sep 07, 2010 at 08:56:53AM +0200, Bernd Wurst wrote: > Am Dienstag 07 September 2010, 08:08:31 schrieb Josias Polchau: > > Ich hatte immer gelernt: > > Entweder Schnell oder Platzsparend. > > Das gilt da aber nicht. Im kleinen stimmt das meistens. > > Wenn aber, wie Flo hier eindrucksvoll gezeigt hat, der Such-Index einerseits > größer ist als der zu erwartende Arbeitsspeicher und andererseits der > Suchindex fast genau so groß ist wie die Daten selbst, dann gilt deine Regel > eben nicht mehr. > > Dann lieber weniger Daten, die man komplett im Arbeitsspeicher halten kann, > diese mit einem groben Index partitionieren und dann in einem Segment > sequenzielle Suche. Das ist schneller als eine Index-basierte Suche auf der > Platte.
Yep - wenn der index nicht mehr in den speicher passt dann macht das Thema SQL nicht mehr sooo viel spass. Und wer hat schon >32GB Speicher. Es lassen sich massgeschneidert viel effizentere index bauen weil wir erstmal davon ausgehen das wir immer eine bounding box setzen. Lieder einfach bounding boxen bauen und dann immer wennns z.b. >1Mbyte/s wird splitten in 2 sub bounding boxes die jeweils ~256Kbyte sind .... Siehe einfach mal TRAPI ... Man muss auch aufpassen das man das feature der platten eher mal nutzt 1MByte in den speicher zu schaufeln als an 20 stellen jeweils nur ein kbyte zu lesen. Flo -- Florian Lohoff f...@zz.de
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
