On Thu, Oct 29, 2015 at 3:01 PM, John R Pierce <pierce@xxxxxxxxxxxx> 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.
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
