The post_name for an od_url_metrics post is comprised of an MD5-hash (via od_get_url_metrics_slug()) of the normalized query vars as returned by od_get_normalized_query_vars(). The normalization is done to avoid creating more od_url_metrics posts than are needed.

For example, when a 404 is returned the URL could contain anything. A request for /?p=123456789 results in query vars including array( 'p' => 123456789 ) even when the post doesn't exist. Every 404 response should be the same, so there is no need to have separate od_url_metrics posts for each 404 response. (In fact, is_404() should perhaps be included in the conditions used by od_can_optimize_response(), although in practice this will be the case since od_get_cache_purge_post_id() will be null.) This is already the case for search queries (when is_search()), since the URL space for searches is by definition unconstrained.) But the situation gets complicated with other types or archive queries. For example, hour, minute, and second are all valid public query vars to get posts by date. Or you can add tag and cat query vars with arbitrary comma-separated lists of tags and categories to create more possible permutations of query vars that will result in unique slug for an od_url_metrics post. How should this be handled?

Note that od_get_normalized_query_vars() isn't sorting the array keys, which is also needed for normalization, $wp->query_vars is populated by iterating over public_query_vars so in practice this shouldn't be a problem.

To guard against infinite permutations in query vars, we should perhaps disable optimization if pretty permalinks aren't enabled and/or if any public query vars are added via $_GET on top of the pretty permalink.