On Mon, Aug 5, 2013 at 2:02 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Hello
>
> 2013/8/5 David Gudeman <dave.gudeman@gmail.com>:
>> For those who don't want to go to the link to see what I'm talking
>> about with query rewrites, I thought I'd give a brief description.
>> Foreign data wrappers currently do all of their work in the planning
>> phase but I claim that isn't the right place to optimize foreign
>> queries with aggregates and GROUP BY because optimizing those things
>> would involve collapsing multiple plan node back into a single node
>> for a foreign call. I propose to do these optimizations as query
>> rewrites instead. So for example suppose t is a foreign table on the
>> foreign server named fs. Then the query
>>
>> SELECT count(*) FROM t
>>
>> is rewritten to
>>
>> SELECT count FROM fs('select count(*) from t') fs(count bigint)
>>
>> where ts() is the pass-through query function for the server fs. To
>> implement this optimization as a query rewrite, all of the elements of
>> the result have to be real source-language constructs so the
>> pass-through query has to be available in Postgresql SQL.
>>
>
> why you introduce new API? There is still dblink.
yeah: FDW infrastructure as it exists today is not really an ad hoc
query tool: you have to (unlike XXXlink) persist global objects for
each command string.
If it was me, in addition to (or instead of) trying to go down the
rathole of exposing optimization mechanics to the FDW driver, I'd be
leaning on some user facing infrastructure to say, parameterize the
query string and/or run ad hoc queries. This would be very useful and
a whole lot less complicated. Note the FDW spec may already have
these facilities; I didn't read it.
merlin
