Thanks, I appreciate you taking the time to do that. I promise I won't make this a debate but I would like to respond to a couple of points, for your consideration.
> Showed up very late in the merge window Yes, for that I apologize, we have our respective timetables and sometimes they coincide and sometimes the interaction is not optimal. Our focuses have been different and then an arbitrary line was drawn in the sand. We would like to work with you here. We have made a few dramatic changes to our approach already to try and accommodate it. > * Is not the green field HFileV3, and doesn't have time for a complete re-do I think it's better actually if a V3 shares as much code as possible with the V2 implementation except for what is actually different, copy-on-write as it were. That said, I may be getting ahead of the latest patch so will wait. > * Can easily be done without out downtime > ** (changing the encoders could be done without needing downtime. meaning no singularity is required). Therefore indeed we can split the work into pre and post singularity. I have not seen the latest patch but the set of pre-singularity change was small before and will be the same or smaller, and post changes that are optional and can be rolled into seems fine, to me, for 0.96.x where x > 0, so there's no conflict here. I wouldn't broach the subject of 1.0 because that is a premature discussion, though I probably don't agree with how you have structured it, at least there is one point of disagreement. > Will 100% have perf impacts. To be pedantic, small cluster (granted) benchmarking does not show a 100% impact. Rather if V2 is used instead of V3 the impact of the changes are not distinguishable from background platform variability. I agree wider testing and probably tuning is necessary before production. There will be other experimental features in 0.96. On Tue, Jul 30, 2013 at 4:08 PM, Elliott Clark <ecl...@apache.org> wrote: > On Tue, Jul 30, 2013 at 3:29 PM, Andrew Purtell <apurt...@apache.org> > wrote: > > Perhaps you can elaborate on the difference you see between HFileV3 and > > namespaces? > > Sure. From my perspective, > > Namespaces: > * arrived earlier in the merge window. > * Has been run publicly on a large cluster > * Has had more public reviews. > * Was re-worked to get closer to a greenfield best implementation > * Is closer to being merged > * Is less prone to have unforeseen perf impacts. > * Is almost impossible to create without needing downtime > ** (hence it should go in the singularity if possible). > > > HFileV3: > * Showed up very late in the merge window > * Still needs revisions > * Hasn't been put on large clusters publicly. > * Is not the green field HFileV3, and doesn't have time for a complete > re-do > * Can easily be done without out downtime > ** (changing the encoders could be done without needing downtime. > meaning no singularity is required). > * Will 100% have perf impacts. > > None of that actually has anything to do with what I think is a more > exciting feature. It's all about stability of the project and trying > to find a way move us towards the stable and externally explainable > release cycles that other real databases have. > > I'm actually really excited about tagging. It could allow a lot of > new and cool features without adding too much core code. > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
