Re: pgsql_fdw, FDW for PostgreSQL server

Shigeru Hanada <shigeru.hanada@gmail.com>

From: Shigeru Hanada <shigeru.hanada@gmail.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Albe Laurenz <laurenz.albe@wien.gv.at>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Kohei KaiGai <kaigai@kaigai.gr.jp>, Martijn van Oosterhout <kleptog@svana.org>, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>, Hitoshi Harada <umi.tanuki@gmail.com>

Date: 2012-04-06T16:14:31Z

Lists: pgsql-hackers

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 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