On Fri, Apr 6, 2012 at 11:20 PM, Tom Lane <t...@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 the FDW 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers