(2012/04/06 1:29), Tom Lane wrote:
> "Albe Laurenz"<laurenz.albe@wien.gv.at> writes:
>> Maybe the FDW API could be extended so that foreign data wrappers
>> can provide a random sample to avoid a full table scan.
>
> The one thing that seems pretty clear from this discussion is that one
> size doesn't fit all. I think we really ought to provide a hook so that
> the FDW can determine whether ANALYZE applies to its foreign tables at
> all, and how to obtain the sample rows if it does.
>
> Since we've already whacked the FDW API around in incompatible ways for
> 9.2, now is probably a good time to add that. I'm inclined to say this
> should happen whether or not we accept any of the currently proposed
> patches for 9.2, because if the hook is there it will provide a way for
> people to experiment with foreign-table ANALYZE operations outside of
> core.
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?
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,
--
Shigeru HANADA