On Wed, Dec 16, 2015 at 1:11 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.
That was Ashutosh's option #3. use_remote_estimate is a pretty expensive option, which is why it's not on by default. But if you are willing to spend that effort for a scan of table A parameterized by a value from table B, it seems likely to me that you are also willing to spend the effort to accurately cost a pushed-down join of A and B. Actually, it seems like it would be more surprising if you weren't: we're willing to accurately cost iterating the scan of B, but not pushing the whole join down? Hmm. That's an arguable position, of course. Actually, I think that neither use_remote_estimate nor !use_remote_estimate is a particularly great option. !use_remote_estimate produces results that are basically pulled out of a hat. use_remote_estimate produces good estimates, but it's pretty expensive for a planning operation. I'd like to have some other alternative, like a local cache of metadata that we can consult when !use_remote_estimate instead of just making things up, which might tell us things like what indexes exist on the remote side. But that's a different project. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers