> > Is there a good way to map back where in the code these calls are coming > from?
There's not a great way currently. I'm trying to get a patch in for Essex which will let deployments easily turn on SQL debugging (though this is proving contentious); it will have a configurable log level to allow for future improvements, and one of the things I'd like to do is add later is something like a stack trace on 'problematic' SQL (large row count, long query time). But that'll be in Folsom, or in G if we don't get logging into Essex. In the meantime, it's probably not too hard to follow the code and infer where the calls are coming from. In the full log, there's a bit more context, and I've probably snipped some of that out; in this case the relevant code is get_metadata in the compute API service and get_instance_nw_info in the network service. > Regardless, large table scans should be eliminated, especially if the > table is mostly read, as the hit on an extra index on insert will be > completely offset by the speedups on select. Agreed - some of these problems are very clear-cut! It does frustrate me that we've done so much programming work, but then not do the simple stuff at the end to make things work well. It feels a bit like shipping we're shipping C code which we've compiled with -O0 instead of -O3.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
