On Wed, Dec 16, 2015 at 11:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > I like option #2. I don't really have a strong reason for that, but
> > it feels intuitive to me that we err on the side of using remote
> > estimates when in doubt.
>
> If we believe that, why isn't the default value of use_remote_estimate
> true?
> (Maybe it should be.)
>
> Another option that should be considered is that joins should pay
> attention only to the server-level setting and not to the individual
> tables' settings. This would surely be cheaper to implement, and
> it avoids any questions about whether to OR or AND the individual
> settings.
>
>
To implement server-level setting, we will need to pull it out of
ForeignServer structure like
442 foreach(lc, fpinfo->server->options)
443 {
444 DefElem *def = (DefElem *) lfirst(lc);
445
446 if (strcmp(def->defname, "use_remote_estimate") == 0)
447 fpinfo->use_remote_estimate = defGetBoolean(def);
...
455 }
whereas use_remote_estimate setting for joining relations is readily
available in PgFdwRelationInfo
58 /* Options extracted from catalogs. */
59 bool use_remote_estimate;
60 Cost fdw_startup_cost;
61 Cost fdw_tuple_cost;
62 List *shippable_extensions; /* OIDs of whitelisted
extensions */
...
76 } ;
This use_remote_estimate is true if server level option is true or table
level option is true.
ANDing or ORing use_remote_estimate from the joining relations'
PgFdwRelationInfo looks cheaper than pulling it out of ForeignServer
structure.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
