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. 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
