On Tue, Jun 30, 2020 at 1:46 PM Joshua McKenzie <jmcken...@apache.org> wrote:
> We're just short of 98 tickets on the component since it's original merge > so at least *some* work has been done to stabilize them. Not to say I'm > endorsing running them at massive scale today without knowing what you're > doing, to be clear. They are perhaps our largest loaded gun of a feature of > self-foot-shooting atm. Zhao did a bunch of work on them internally and > we've backported much of that to OSS; I've pinged him to chime in here. > Probably true. > > The "data is orphaned in your view when you lose all base replicas" issue > is more or less "unsolvable", since a scan of a view to confirm data in the > base table is so slow you're talking weeks to process and it totally > trashes your page cache. "Make the scan faster" "Make the scan incremental and automatic" "Make it not blow up your page cache" "Make losing your base replicas less likely". There's a concrete, real opportunity with MVs to create integrity assertions we're missing. A dangling record from an MV that would point to missing base data is something that could raise alarm bells and signal JIRAs so we can potentially find and fix more surprise edge cases. > So from my PoV, I'm against us just voting to deprecate and remove without > going into more depth into the current state of things and what options are > on the table, since people will continue to build MV's at the client level > which, in theory, should have worse correctness and performance > characteristics than having a clean and well stabilized implementation in > the coordinator. > Yanking features will definitely be painful for users. Leaving it experimental seems much better for users as long as the maintenance overhead is tolerable.
