On Thu, Oct 29, 2015 at 3:01 PM, John R Pierce <pie...@hogranch.com> wrote:
> On 10/29/2015 11:20 AM, Dane Foster wrote: > > I think you are correct about mysql_fdw "... sending the trim() checks > for remote execution" because according to the docs: > > "The latest version will push-down the foreign table where clause to the > foreign server. The where condition on the foreign table will be executed > on the foreign server hence there will be fewer rows to to bring across to > PostgreSQL. This is a performance feature." > > > the alternative would be to fetch the whole table across the FDW > interface, then run the where locally, for a large table where you're only > selecting a few rows, this would be very painful. > > I guess using mysql_fdw is a no-go for my data migration needs. > > > or, rewrite that WHERE clause to be mysql compatible. > Easier said than done because the LENGTH and TRIM functions both exist in MySQL but I guess under the covers in PostgreSQL btrim is being invoked when TRIM is called therefore that is what is being "pushed down" to the MySQL and there is nothing I can do about that. I guess I could leave out the call to trim, and copy the data into a temp table on the PostgreSQL side, and blah blah blah. My point being why should I have to jump through hoops because mysql_fdw is broken? I'll just go back to writing the migration script as a PHP program because if mysql_fdw didn't exist that's what I would have to do anyway. > > -- > john r pierce, recycling bits in santa cruz > > Dane
