> Sinon, je serais interessee par les query que tu as mis en place :) > Je ne me preoccupe pas du tout d'affichage mais je serais interessee par > les optimisations que tu obtiens.
en moyenne c'est de la bidouille "essais/erreurs", mais je files tout librement : http:///beta.letuffe.org/mapnik-styles > Par experience, Postgis a du mal avec les tres grosses geometries. De > plus, il existe un bug connu lie au pages TOAST qui ne tiennent pas > compte de la taille de la geometrie. > Si la table est relativement petite et que la geometrie est enorme, les > index seront ignores par le planner de Postgres au profit d'un scan. > C'est quelque chose que j'ai deja subi. J'ai resolu le probleme en ne > faisant plus de scan sur la table qui posait probleme :p > Plus serieusement, la solution generalement dans ce cas la est de > decouper les geometries, en partie plus petites avec un nombre limite de > points. Cela permet d'augmenter le nombre de ligne et de reduire la > taille de la geometrie. > A noter que je parle d'un cas totalement different en premier lieu, donc > ca peut ne pas s'appliquer a ce que tu fais. > > Emilie Laffray > > sly (sylvain letuffe) wrote: > >> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être > >> tenter un simplify() sur la colone geometry, avant de passer aux > >> fonctions qui bourrinent. > >> > > > > Et bien l'idée valait le coup d'être tentée, y'a pas à chier, ça gagne en > > temps : > > sans st_simplify : > > http://beta.letuffe.org/cartes/communes.png : 1 minutes 30 > > > > avec : > > http://beta.letuffe.org/cartes/communes2.png : 15 secondes > > > > ( avec ST_SimplifyPreserveTopology : > > http://beta.letuffe.org/cartes/communes3.png : 1 minute) > > > > Hélas comme j'en avais peur, le st_simplify sort des géométries valides sur > > la > > base de géométries non valides (le ST_SimplifyPreserveTopology semble > > carrément toutes les corriger ) > > > > Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses > > géométries type départements avant de les donner à mapnik et ça gagne de > > 20 à 30% > > (parfois bien plus, mais je pense heurter un problème de tunning de mon > > postgres qui doit s' emmêler les buffers ) > > > > A noter finalement que après tous ces tests, une vérité revient super > > régulièrement : Ce sont les disques durs qui sont limitant. > > > > Si je lance deux rendus identiques à la suite l'un de l'autre (histoire que > > le > > noyau linux me laisse tout dans un cache RAM) le temps varie de diviser par > > 3 > > à diviser par 10. > > > > Conclusion : mettre 16Go de RAM et laisser la base postgis sur un > > RAM-disque ;-) > > > > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
