> > My concerns have consistently been more fundamental - the basic properties > of a theoretically bug-free MV are simultaneously problematic and unknown. > How can we say we have a working feature, when we our definition of > ‘working’ is unknown?
Well, we know to some extent that MV's are theoretically possible, because they work as is. There might be limitations to the design, as I know you've raised before and were ignored, if that's what you're referring to here. But for the most part they have been working just fine bar implementation bugs. I wouldn't go as far as saying our definition of working is unknown, that's a tad over the top. As I've already said, if you're aware of some serious fundamental flaws, it shouldn't be too difficult to point them out. I'd suspect they would have already been encountered so evidence shouldn't be hard to find. We have unsafe defaults Yeah we do, but don't be changing them in a patch release. For the record, MV's aren't something that is automatically created that everyone has to deal with, it's still opt-in. I think incremental repairs and vnodes are far worse defaults, and cause much more damage. Nobody in the wild is even using MVs in the way they were designed, because > they were too slow. In no other endeavour have we gone “well, it’s too > slow, so let’s just accept data loss by default” > How exactly can you use MVs in a way different from how they were designed? I don't understand, all the use cases I've seen have been perfectly legitimate. I mean, you can use them with a bad data model, but I wouldn't say that's not the way they were designed. That's possible for normal tables as well. In no other endeavour have we gone “well, it’s too slow, so let’s just > accept data loss by default” > Most people we've talked to prefer the simplicity of using MV's over the speed. I don't know what the sentiment was at the beginning, but in the past several months we've only cared about correctness, not speed. Anyway, if there are fundamental flaws then they need to be addressed. As soon as possible. I'm still going to tell you that telling existing users who have already gone down this path that the feature is no longer supported in production is a terrible idea. You are telling users "actually you need to stop using that and re-write all your applications and do it all yourself because we screwed up". It doesn't magically remove any fault on our part for putting it in in the first place. The correct solution for us and the users is to fix these issues, as soon as possible, and alert everyone to the fact that these problems can occur. If we can't fix it, then we can turn it off in the next major, otherwise we should just note the flaws and restrict any functionality that just isn't going to work.
