Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Oct 5, 2010 at 10:25 AM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
