Shigeru HANADA <shigeru.hanada@gmail.com> writes:
> (2012/04/06 1:29), Tom Lane wrote:
>> 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.
> 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.
Sorry, I used the word "hook" loosely, not with the intention of meaning
a global function pointer. We should of course implement this with
another per-FDW method pointer, as in the postgresql-analyze patch
series.
> Another concern is the place where we hook the process of ANALYZE. IOW,
> how much portion of ANALYZE should be overridable?
Not much, IMO. The FDW should be able to decide whether or not to
analyze a particular table, and it should be in charge of implementing
its own version of acquire_sample_rows, but no more than that. In
particular I do not like the specific way it's done in the v7 patch
(I've not looked at v8 yet) because the interposed logic has a
hard-wired assumption that foreign tables do not have inheritance
children. I think that assumption has a life expectancy measured in
months at most, and I don't want to have to try to fix every FDW when
it changes. But I think we can easily revise the hook details to fix
that, and I'm hoping to get that done today.
regards, tom lane
