Hi, On 2019-04-15 15:19:41 -0400, Tom Lane wrote: > Peter Geoghegan <p...@bowt.ie> writes: > > I am also concerned by the broad scope of ZedStore, and I tend to > > agree that it will be difficult to maintain in core. At the same time, > > I think that Andres and Robert are probably right about the difficulty > > of maintaining it outside of core -- that would be difficult to > > impossible as a practical matter. > > Perhaps, but we won't know if we don't try. I think we should try, > and be willing to add hooks and flexibility to core as needed to make > it possible. Adding such flexibility would be good for other outside > projects that have no chance of (or perhaps no interest in) getting into > core, even if we end up deciding that ZedStore or some other specific > implementation is so useful that it does belong in core.
I don't think anybody argued against providing that flexibility. I think we should absolutely do so - but that's imo not an argument against integrating something like a hypothetical well developed columnstore to core. I worked on tableam, which certainly provides a lot of new extensibility, because it was the sane architecture to able to integrate zheap. The current set of UNDO patches (developed for zheap), while requiring core integration for xact.c etc, co-initiated improvements to make the checkpointer fsync being closer to extensible and UNDO as currently developed would be extensible if WAL was extensible as it's tied to rmgrlist.h. And the improvements necessary to make query executions for in-core columnar AM faster, would largely also be applicable for out-of-core columnar AMs, and I'm sure we'd try to make the necessary decisions not hardcoded if reasonable. I think it's actually really hard to actually make something non-trivial extensible without there being a proper in-core user of most of that infrastructure. Greetings, Andres Freund
