On Fri, Jul 15, 2016 at 5:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes: >>> Here is a patch for that redesign proposed by you; reverts commits >>> fbe5a3fb73102c2cfec11aaaa4a67943f4474383 and >>> 5d4171d1c70edfe3e9be1de9e66603af28e3afe1, adds changes for that redesign >>> to the core, and adjusts the postgres_fdw code to that changes. Also, I >>> rearranged the postgres_fdw regression tests to match that changes. > >> OK, I'll review this later today. > > Pushed, after fooling around with it some more so that it would cover the > case we discussed where the join could be allowed if we restrict the plan > to be executed by the owner of a view used in the query.
Mumble. Why, exactly, was this a good idea? The upside of commit 45639a0525a58a2700cf46d4c934d6de78349dac is only that you do fewer plan invalidations, but surely that's not a significant benefit for most people: user mappings don't change that often. On the downside, there are now cases where joins would have gotten pushed down previously and now they won't. In other words, you've saved some replanning activity at the cost of delivering worse plans. That seems pretty suspect to me, although I grant that the scenarios where either the old or the new behavior is actually a problem are all somewhat off the beaten path. -- 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
