Re: mysql_fdw trouble

On Thu, Oct 29, 2015 at 3:01 PM, John R Pierce <pierce(at)hogranch(dot)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 LENG​TH 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​