>>Now this sounds more realistic, and more likely to deliver some good results. Hopefuly an optimization in one direction won't make later optimizations into other directions impossible; if they're just a bit hard to do, or time-consuming (once, not on every request :), that'll be OK for me.
>
>Not impossible...it will break the first optimization. For example, inserting records is very expensive when you have lots of indexes. But, indexes are what optimize a query. You can't have both..or you settle on something in the middle that gives satisfactory, but not optimal results to both the insert and the query.

No surprise - this issue is as old as the indexing itself. The more indexes, the more work at insertion, and proportionally quicker retrieval. Rushmore just eased it, but never really removed the problem, because it can't be removed. Can't get something from nothing, and indexing is just an investment.

Of course, it's the DB designer's job to pick an optimal set of tags, as it always was. I didn't expect SQL server or any kind of software to try to be smart at this point. Thinking of it, I also wouldn't like it to pick permanent tags to create without asking me first.