Excuse me for cutting in,
2012/4/6 Shigeru HANADA <shigeru.hanada@gmail.com>:
> To support foreign-table ANALYZE by adding a new hook, we would need a
> mechanism (or at least documented guide lines) to manage the chain of
> hook functions, because such hook might be used by multiple FDWs (or
> other plug-ins) at the same time. A wrongly-written plug-in can easily
> break the hook chain. We might need to provide register/unregister API
> for this hook point, like RegisterResourceReleaseCallback, and call each
> registered function until either of them processes the request. Is
> there any other hook point which has similar issue?
+1
Plain hook mechanism in PostgreSQL is, I think, to hang a bunch
of faceless callbacks to be registered, unregistered and called
all together. And it does not fit to manage individual callbacks
which may be registered or unregistered in arbitrary order and
are preferred to be called separately.
Although we provide RegisterResourceReleaseCallback-like staff,
it seems far more complicated than the additional field in
FdwRoutine and some analyze_rel() modifications in core-side, and
confirmation of whether it's really the time for me should be a
reluctant work in plugin-side.
Of cource, I don't think there will be so many fdw-analyze
callbacks registered but two seems sufficient.
The current mods in analyze_rel() does not look definitive, but
it does not look so bad and seems more stable than simple hook
point which will be abandoned before long.
> Another concern is the place where we hook the process of ANALYZE. IOW,
> how much portion of ANALYZE should be overridable? Replacing
> analyze_rel or do_analyze_rel wholly requires plug-ins to copy most of
> codes from original function in order to implement hook function. From
> the perspective of FDW author, I think that row sampling
> (acquire_sample_rows) function seems handy place to hook.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center