Re: patch: SQL/MED(FDW) DDL
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Shigeru HANADA <hanada@metrosystems.co.jp>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, SAKAMOTO Masahiko <sakamoto.masahiko@oss.ntt.co.jp>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-10-05T14:41:26Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Oct 5, 2010 at 10:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> This whole discussion seems to me to be about trying to do things outside >> the FDW that should properly be left inside the FDW. Who's to say that >> the remote side even *has* statistics of the sort that PG creates? >> >> We should provide an API that lets the FDW return a cost estimate for a >> proposed access path. Where it gets the cost estimate from is not >> something that should be presupposed. > Unless there's some way for the FDW to have local tables for caching > its statistics, the chances of this having decent performance seem to > be near-zero. Perhaps, but that would be the FDW's problem to implement. Trying to design such tables in advance of actually writing an FDW seems like a completely backwards design process. (I'd also say that your performance estimate is miles in advance of any facts; but even if it's true, the caching ought to be inside the FDW, because we have no clear idea of what it will need to cache.) regards, tom lane