On Fri, Dec 18, 2015 at 6:39 PM, Albe Laurenz
wrote:
> Ashutosh Bapat wrote:
> > Costs for foreign queries are either obtained from the foreign server
> using EXPLAIN (if
> > use_remote_estimate is ON) otherwise they are cooked up locally based on
> the statistics available. For
> > joins as well
Robert Haas wrote:
>> Maybe, to come up with something remotely realistic, a formula like
>>
>> sum of locally estimated costs of sequential scan for the base table
>> plus count of estimated result rows (times a factor)
>
> Was this meant to say "the base tables", plural?
Yes.
> I think whatever
On Fri, Dec 18, 2015 at 8:09 AM, Albe Laurenz wrote:
> My gut feeling is that for a join where all join predicates can be pushed
> down, it
> will usually be a win to push the join to the foreign server.
>
> So in your first scenario, I'd opt for always pushing down the join
> if possible if use_
Ashutosh Bapat wrote:
> Costs for foreign queries are either obtained from the foreign server using
> EXPLAIN (if
> use_remote_estimate is ON) otherwise they are cooked up locally based on the
> statistics available. For
> joins as well, we have to do the same. If use_remote_estimates [1] is ON,
Hi All,
Costs for foreign queries are either obtained from the foreign server using
EXPLAIN (if use_remote_estimate is ON) otherwise they are cooked up locally
based on the statistics available. For joins as well, we have to do the
same. If use_remote_estimates [1] is ON, we can get the costs from
