Simon Riggs <simon@2ndQuadrant.com> writes:
> [ assorted comments about custom-scan patch, but particularly ]
> * The prune hook makes me feel very uneasy. It seems weirdly specific
> implementation detail, made stranger by the otherwise lack of data
> maintenance API calls. Calling that for every dirty page sounds like
> an issue and my patch rejection indicator is flashing red around that.
Yeah. After a fast review of the custom-scan and cache-scan patches, it
seems to me that my original fears are largely confirmed: the custom scan
patch is not going to be sufficient to allow development of any truly new
plan type. Yeah, you can plug in some new execution node types, but
actually doing anything interesting is going to require patching other
parts of the system. Are we going to say to all comers, "sure, we'll put
a hook call anywhere you like, just ask"? I can't see this as being the
way to go.
Another way of describing the problem is that it's not clear where the API
boundaries are for potential users of a custom-scan feature. (Simon said
several things that are closely related to this point.) One thing I don't
like at all about the patch is its willingness to turn anything whatsoever
into a publicly exported function, which basically says that the design
attitude is there *are* no boundaries. But that's not going to lead to
anything maintainable. We're certainly not going to want to guarantee
that these suddenly-exported functions will all now have stable APIs
forevermore.
Overall I concur with Simon's conclusion that this might be of interest
for R&D purposes, but it's hard to see anyone wanting to support a
production feature built on this. It would be only marginally less
painful than supporting a patch that just adds the equivalent code
to the backend in the traditional way.
So I'm feeling that this was kind of a dead end. It was worth doing
the legwork to see if this sort of approach could be useful, but the
answer seems like "no".
regards, tom lane