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
