On Mon, Aug 5, 2013 at 2:02 PM, Pavel Stehule wrote:
> Hello
>
> 2013/8/5 David Gudeman :
>> 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 plann
On Tue, Aug 6, 2013 at 12:51 AM, Tom Lane wrote:
> David Gudeman writes:
> > 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
> > phas
On Mon, Aug 5, 2013 at 12:21 PM, Tom Lane wrote:
> David Gudeman writes:
>> 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
David Gudeman writes:
> 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
Hello
2013/8/5 David Gudeman :
> 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
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 GRO
On Tue, Jul 30, 2013 at 10:22 PM, Tom Lane wrote:
> David Fetter writes:
>> On Tue, Jul 30, 2013 at 04:40:38PM -0700, David Gudeman wrote:
>>> When you write an application involving foreign tables, you frequently
>>> end up with queries that are just too inefficient because they bring
>>> too mu
On Wed, Jul 31, 2013 at 01:22:56AM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Tue, Jul 30, 2013 at 04:40:38PM -0700, David Gudeman wrote:
> >> When you write an application involving foreign tables, you frequently
> >> end up with queries that are just too inefficient because they bring
David Fetter writes:
> On Tue, Jul 30, 2013 at 04:40:38PM -0700, David Gudeman wrote:
>> When you write an application involving foreign tables, you frequently
>> end up with queries that are just too inefficient because they bring
>> too much data over from the foreign server. For a trivial examp
On Tue, Jul 30, 2013 at 04:40:38PM -0700, David Gudeman wrote:
> When you write an application involving foreign tables, you frequently
> end up with queries that are just too inefficient because they bring
> too much data over from the foreign server. For a trivial example,
> consider "SELECT coun
When you write an application involving foreign tables, you frequently
end up with queries that are just too inefficient because they bring
too much data over from the foreign server. For a trivial example,
consider "SELECT count(*) FROM t" where t is a foreign table. This
will pull the entire tabl
11 matches
Mail list logo
