tag proposal

[Dustin Sallings]

On Oct 3, 2007, at 23:48, Clint Webb wrote:

> I personally do not see the need to use tags in any other way  
> except to easily remove (invalidate?) keys that have a particular  
> tag.  Being able to do other things like retrieve all keys that  
> have a tag, could be useful, but I can see it as complicating things.

	It's not that it it's complicated, but it falls under the same  
category of listing keys that causes the server to hang while someone  
calls it.

> First point.  When you say 'invalidate_tag' I assume you mean to  
> invalidate all keys that have that tag.

	Correct.

> Second point.  You ask the question about refcounts on tags, I  
> think it should, or at the very least provide a command that will  
> tell the cache to remove all tags that are no longer referenced by  
> a key.  Refcount is probably easier, and just remove the tag when  
> it gets to zero.  Decrementing it when a key is deleted or  
> expired.   Otherwise, memory used by tags will always keep getting  
> bigger as keys drop out due to LRU.   An example, article 50 is  
> added to the cache, and tags representing that article ID have been  
> added to a bunch of keys.  Over time, article 50 no longer has much  
> visibility and falls out of the cache due to LRU.  If no more keys  
> are in the cache for the tag, I think the tag should go.

	It really depends on how often a tag is *not* used again.  If tags  
are generally reused, it makes things more expensive and  
complicated.  It could also lead to a lot of memory churn unless  
there's a memory pool for tags as well.

	If tags are often not reused, it would be a memory leak.

> Third point.  I am also assuming that we can assign more than one  
> tag to a key.  If I could only add one tag to a key, then that  
> would limit its usefulness to me.  I see you mention pointers (and  
> not just pointer) so I am sure that this is correct, just clarifying.

	Absolutely.  Each item may have zero or more tags.

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071004/c14bac72/attachment.htm