Check out the previous post Filter using 'wpseo_typecount_where' in 'build_root_map', it is related to this.
I found that problem when looking into database saturation and an unusual number of 404 errors coming from the search crawlers. We have a large number of child (post_status == inherit) posts (80,000+) that hold data and are not directly displayed (It's a WPEC site).
The plugin was generating sitemaps containing these URLS that have should not be known to the search engines. Using the build in filter to override the posts that are retrieved is a great option.
But what is happening is search engines still know the old sitemap URLs. And I am still seeing the table scans.
When the old sitemap url is requested by the crawler, plugin tries to get for example sitemap #300. The query that executes is doing a full table scan. I believe this is because the password field in the wp_posts table is not indexed and is part of the query string. If a few requests for high index sitemaps come in close together these full table scans have a serious impact on the site performance. Sometimes knocking it over.
This might be a DOS vulnerability for a site with a large number of posts that is using the plugin. The DOS scenario to cause the problem would be send a series of bogus requests for high index sitemaps. When the plugin goes to the DB to get the related records from the posts table the DB server could be saturated, or even exhaust available virtual resources trying to service the requests.
I also could be mistaken?