On 10/29/2015 12:10 PM, Dane Foster wrote:
> On Thu, Oct 29, 2015 at 3:01 PM, John R Pierce <pierce@hogranch.com
> <mailto:pierce@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.
Remember you are using a Beta version of Postgres, so it is not entirely
unexpected that things might be broken, especially when working with
non-core extensions. In the spirit of testing, that Beta implies, why
not help fix mysql_fdw by filing an issue? If you already have, my
apologies.
>
>
> --
> john r pierce, recycling bits in santa cruz
>
> Dane
>
--
Adrian Klaver
adrian.klaver@aklaver.com
