On Fri, Apr 6, 2012 at 11:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
ISTM that we have rough consensus about what FDW should do for an
ANALYZE request. FDW should choose either of: a) get sample rows and return them to backend b) tell backend that
theFDW has nothing to do for the request
> 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.
I'll try implementing the design you suggested.
Regards,
--
Shigeru Hanada
