Shigeru HANADA <shigeru.han...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers