Hi,
On 2019-04-15 15:19:41 -0400, Tom Lane wrote:
> Peter Geoghegan <pg@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