Moritz L: > >>> Then testing the idea from the link Markus N added to your bug report:
> >>> time v.db.update mygrid col=count value="(SELECT count(*) from mypoints > >>> WHERE mygrid.cat=mypoints.cat_municip group by cat_municip)" > >>> real 5m28.312s > >> And to show the magic of database indices: > >> time echo "create index mypoints_cat_municip on mypoints (cat_municip)" > >> | db.execute && time v.db.update mygrid col=count value="(SELECT > >> count(*) from mypoints WHERE mygrid.cat=mypoints.cat_municip group by > >> cat_municip)" > >> > >> real 0m10.113s > >> user 0m6.320s > >> sys 0m1.300s > >> > >> real 0m0.668s > >> user 0m0.544s > >> sys 0m0.124s Markus M: > > Thanks a lot! This index was missing here on my sqlite tables. To > > throw in another timing with 600 000 random points: > > > > time v.distance from=randpoints_600K from_layer=1 to=boundary_municp > > to_layer=1 to_type=area upload=cat column=to_cat > > (no dmax, a nearest area was found for each point) > > > > real 3m26.308s > > user 1m49.736s > > sys 1m35.067s Seeing the various timings I' ve got the impression that I did something completely wrong. > Estimate for grass 6: >6 hours Reading this means there was a "problem" after all, right? > > same with dmax=0.0 > > 558294 categories - no nearest feature found <-- expected > > > > real 1m24.819s > > user 0m42.511s > > sys 0m41.384s > > tuned v.distance in trunk r43042 Anyhow, the above timing is perfect! I "couting time right now" in grass64, in grass70 (both before and after latest v.distance update). Let's see... :-) Thank you, Nikos _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
