4 ms·

> Something you usually do not do with tags: "give me a list of every tag that the system has ever seen used on a post" I'm thinking of the times I've used tag

> Something you usually do not do with tags: "give me a list of every tag that the system has ever seen used on a post" I'm thinking of the times I've used tags in my webapp and in all cases I've had to do: "for this subset of records what are all the tags?" And in one case, "what are all the tags we're using?" Does that mean using postgres native arrays as tags would be a bad idea in those cases? I read this article with interest because we've been using acts-as-taggable a fair amount.

saurik 13y ago
If you consider this kind of query common or important, you run into a problem where that information is not exposed via the semantics of storing a tag cloud per item. It just so happens that at an implementation level, PostgreSQL could very easily answer the "all tags" query if using a GiN index, but AFAIK does not expose that to the developer. For a GiST index, that information simply does not exist. You could now simulate the information for the all tags case by using a table of tags that you garbage collect by using efficient "are there still any posts with this tag on them" queries whenever you change a tag cloud, but that is now a separate reverse-denormalized data structure you are maintaining in the database. For "show me all tags used by a subset of posts", though: that use case sucks either way, and tha array is probably better. For the relation, you are doing a select distinct off a join, and in the tag cloud solution you are doing a set merge aggregation. The tag loud is going to be more efficient, but neither is indexable, do it doesn't really matter in a way (you should just avoid the user needing to make that query ;P).