While this looks like a nice performance improvement, it doesn't actually address #10452. A solution to #10452 would cache the fact that the database query was just performed and returned a 404, so that a subsequent request would skip any database query altogether.

@chiatt we can do that, but I would strongly advise adding in some logic that embeds the state of the db into the cache key so that we avoid a case where a 404 was cached, then a new geom was created but it doesn't get included in a tile because the cache hasn't timed out yet.

For example:

cache_key = create_mvt_cache_key(node, zoom, x, y, request.user)
...

def create_mvt_cache_key(node, zoom, x, y, user, mvt_snapshot=None):
    if not mvt_snapshot:
        mvt_snapshot = models.EditLog.objects.filter(nodegroupid=str(node.nodegroup_id)).count()
    return f"mvt_{str(node.nodeid)}_{zoom}_{x}_{y}_{mvt_snapshot}_{user.id}"

still testing a couple alternative approaches here

@chiatt we can do that, but I would strongly advise adding in some logic that embeds the state of the db into the cache key so that we avoid a case where a 404 was cached, then a new geom was created but it doesn't get included in a tile because the cache hasn't timed out yet.

For example:

cache_key = create_mvt_cache_key(node, zoom, x, y, request.user)
...

def create_mvt_cache_key(node, zoom, x, y, user, mvt_snapshot=None):
    if not mvt_snapshot:
        mvt_snapshot = models.EditLog.objects.filter(nodegroupid=str(node.nodegroup_id)).count()
    return f"mvt_{str(node.nodeid)}_{zoom}_{x}_{y}_{mvt_snapshot}_{user.id}"

If the value is different between what is saved to the cache when a user gets a 404 vs an MVT tile, then it seems ok to return no tile even if an editor has recently created a new geometry within those bounds. That's the price of relying on a cache, and the cache timeout can always be adjusted to an admin's preference for performance over accuracy.

@chiatt the SELECT COUNT query should leverage Postgres indexes and caching (vs a regular SELECT query) so while it does represent a query, it's still performant. If we want to basically rule out creating any new queries on principal, the alternative/workaround would be to cache a count of the all editlog objects every time a new editlog instance gets created. I would be a little surprised though if removing the SELECT COUNT query actually sped things up by more than a hundred milliseconds.

It really seems like this should offer a nice performance improvement, but when I look at request times in Silk, I'm not seeing any improvement. It might be that I'm not testing it with the right data because I'm sure the scale and distribution of points makes a difference. Also, the additional query to the edit log is probably increasing the request time by a wee bit as well.

How many geometries does the resource layer you're testing with have? I would expect little to no improvement for lower-density resource-layers but once you get into the tens of thousands I would expect noticeably faster responses for MVT requests.