[OSM-Devserver] Partitionierung

[Frederik Ramm]

Hallo,

Kai Krueger wrote:
> Ohne index benoetigt der querry ca 960ms,
> Fuer "where highway is not null" is es dann ca. 930ms
> und bei dem vollen "where highway in 
> ('motorway','motorway_link','trunk','trunk_link','primary','primary_link','secondary','secondary_link','tertiary','tertiary_link','residential','unclassified','minor','road','service','pedestrian','raceway','living_street')" 
> sind es immer noch 850ms.

Wenn Du das Test-Setup noch da hast, gib uns mal die Vergleichszahl fuer 
ohne "order by z_order". Ich glaub naemlich, das ist der Boesewicht.

> Und das waren schon die recht einfachen queries. Viele der queries die 
> mapnik macht haben wesentlich mehr "or" Verknuepfungen, so dass man im 
> Prinzip fuer jeden querry (und davon gibt es viele) einen separaten 
> index benoetigt.

Ich dachte, dass wir nicht primaer ueber eine Optimierung fuers 
Rendering reden, sondern allgemein? Was Mapnik betrifft hast Du zwar 
recht, andrerseits sind es auf jedem Zoomlevel doch einige wenige 
Queries, die den Loewenanteil der Zeit verbrauchen, und da lohnt es sich 
schon, ein bisschen zu feilen.

> Nicht nur verliert man dann also bei den Updates, da man wesentlich mehr 
> indexe pflegen muss,

Probiere das aber mal aus. Der create index fuer so einen partial index 
dauert auf dem ganzen Planeten (!) in der Regel nur wenige Sekunden. Ist 
das nicht Anlass zur Annahme, dass auch die Aktualisierung solcher 
Indexe nicht allzu teuer sein kann?

> Bevor man irgendwelche indexe hinzufuegt sollte man also recht genau 
> eine statistische Analyse machen, welche Abfragen im Durchschnitt ab 
> meisten Zeit benoetigen ( also die Kombination aus wie haeufig werden 
> die Abfragen verwendet und wie lange braucht jede davon) und ob das 
> insgesamt prozentual ein nennenswerter Anteil des Gesamten ist.

Wobei, wenn ich es richtig verstanden habe, hier das Ziel ja nicht so 
spezifisch war.

Bye
Frederik