On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: >> Yes, I think that's broadly the approach Tom was recommending. > > I don't have problem with that approach, but the latest patch has > following problems. > 1. We are copying chunks of path creation logic, instead of reusing > corresponding functions.
Exactly which functions do you think we ought to be reusing that the patch currently doesn't reuse? > 2. There are many cases where the new function would return no local > path and hence postgres_fdw doesn't push down the join [1]. This will > be performance regression compared to 9.6. Some, or many? How many? Which ones? At least some of the problems you were complaining about look like basic validity checks that were copied from joinpath.c, so they're probably necessary for correctness. It's worth remembering that we're trying to fix a bug here; if that makes some cases perform less well, that's sad, but not as sad as throwing a bogus error, which is what's happening right now. I'm a bit sketchy about this kind of thing, though: ! if (required_outer) { ! bms_free(required_outer); ! return NULL; } I don't understand what would stop that from making this fail to generate parameterized paths in some cases in which it would be legal to do so, and the comment is very brief. -- 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