OK mais Overpass ne dispose encore d'aucun canal de remontée d'infos statistique (ne serait-ce que sous forme de texte brut sous forme de commentaire à charge ensuite au développeur de l'interpréter, comme le fait Wikimedia quand il parse un page en générant en fin de page un bloc de commentaire HTML dans le HTML qu'il génère). C'est ce canal qu'il faut mettre en place et ensuite alimenter en y remontant des infos de la source SQL sous-jascente : temps d'exécution, ressources mémoire, taux de charge du serveur, volumétries, sélectivités mesurées ou estimées par le moteur, nombre d'I/O, voire même avec des options sous forme de flags passables dans les requêtes permettant de montrer plus de détails des plans d'exécution demandés, mais attention à ne pas remonter des donnés internes "sensibles" pour la sécurité, c'est ce qui peut être bloquant si on ne sait pas ce qui peut être remonté, il ne faudrait pas remonter par exemple des chemins d'accès privés, des cookies de session, des mots de passe d'accès, etc via les traces de débogage non filtrées).
Le 6 novembre 2014 21:21, Pierre Béland <pierz...@yahoo.fr> a écrit : > Disons simplement, qu'effectivement ce devrait être à l'application > d'optimiser une telle requête. Et nous donner un minimum de > rétro-information en nous disant le coût de la requête (temps ordinateur). > > > Des améliorations qui pourront sans doute venir éventuellement pour > faciliter l'accès à tous. > > Pierre > > ------------------------------ > *De :* Philippe Verdy <verd...@wanadoo.fr> > *À :* Discussions sur OSM en français <talk-fr@openstreetmap.org> > *Envoyé le :* Jeudi 6 novembre 2014 15h05 > *Objet :* Re: [OSM-talk-fr] Overpass : réponse tronquée > > certaines formes d'expressions régulières simples pourraient être > reconnues et traduites en traduisant les "or" simples en unions > équivalentes. Mais le moteur Overpass n'a pas d'optimiseur statistique lui > permettant de choisir à la volée quelle forme est la meilleure. parfois > l'expression régulière est plus efficace même si elle impose un full stable > scan et abandonner la fusion d'accès indexés vers une table temporaire. > Overpass n'est pas un moteur SQL et n'a aucune idée des volumétries et > probabilités et le moteur SQL sous-jascent ne sait pas non plus toujours > convertir une union utilisant une table temporaire de fusion d'index en un > seul table scan (cela dépend d'autres critères des requêtes qui peuvent > avoir des sélectivités plus précises applicables avant dan le plan > d'exécution des requêtes. Le moteur SQL sous-jascent et sa version > jouentaussi pour beaucoup dans les formes équivalentes qu'il peut > reconnaitre, et il lui faut aussi des données en terme d'I/O et formats de > tables, types de stockage local ou "remote", cachabilité des données en > mémoire, etc... > En fait c'est le moteur SQL qui est le mieux armé pour effectuer ce genre > d'optimisation et non le moteur Overpass. Il n'y a pas de façon absolument > meilleure qu'une autre sauf l'expérience avec une instance installée > spécifique et les "règles" qu'on pourrait s'imposer peuvent varier. Pour > développer ses requêts on doit alors s'appuyer sur l'expérimentation et > faire attention aux changements de versions des logiciels et matériels > sous-jascents et leur configraituon. Overpas n'offre pas de vue directe > permettant de visualiser les plans d'exécution qu'il génère vers sont > interface SQL, au moins à titre de débogage et analyse. Bref l'optimisation > reste à faire manuellement en changeant l'ordre d'écriture des critères et > en s'interrogeant sur les sélectivités et la volumétrie "à vue de nez". > Au moins avec Overpass on dispose de certains outils comme la possibilité > de mettre des limites de volumétrie pour faire des tests et savoir si une > limite (row count) est atteinte ou pas dans les limites de temps > d'exécution (pouvoir expérimenter sur un extrait arbitraire de données) et > mesurer les temps d'exécution afin de construire "dynamiquement" plusieurs > requêtes logiquement équivalentes à partir de mesures faites sur des > fragments de sous-requêtes., mais si les limites de volumétrie (row counts) > sont exploitables les limites de temps d'exécution et d'espace de stockage > temporaire ne le sont pas facilement (d'autant que cela dépend aussi de la > charge des serveurs, donc de ce que font les autres utilisateurs dans le > même temps) > > > Le 6 novembre 2014 20:26, Jérôme Seigneuret <jseigneuret-...@yahoo.fr> a > écrit : > > A voir aussi le délais que tu passes dans la requête overpass *timeout* . > > Après il est vrai que faire une requête type like sur des valeurs précise > c'est pas à faire. Il y a eu une demande pour prendre en compte les "and" > et "or" pour des valeurs précise dans overpass. > > > > Le 6 novembre 2014 18:22, Yves Pratter <yves.prat...@gmail.com> a écrit : > > Pierre > > lorsque je sélectionnais <has-kv k="highway" > regv="trunk|primary|secondary" /> le téléchargement s'arrêtait en cours de > route. > > Les expressions rationelles prennent du temps. Dans ton cas tu veux les > trunk *et* les primary *et* les secondary, donc pas besoin de ces > expressions. > > essaie ceci qui doit être plus efficace : > > <union> > <query type=‘way’> <has-kv k="highway" v="trunk" /> > > </query> > > <query type=‘way’> <has-kv k="highway" v=« primary" /> > > </query> > > <query type=‘way’> <has-kv k="highway" v=« secondary" /> > > </query> > > </union> > > — > Yves > > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
