List:Internals« Previous MessageNext Message »
From:Jay Pipes Date:June 19 2007 12:38pm
Subject:Re: Rationale behind FEDERATED engine queries
View as plain text  
Peter B. Volk wrote:
>> What's the reason for not sending the original query
>> to
>> the remote server?
> 
> # Select all rows that have to be deleted
> # Send them to the "virtual int delete_row (buf);" function of the storage
> engine. The Buf contains the row to be deleted. The storage engine does
> not "know" the real query. Actuall this is rather logical. Delete
> statements may also contain Select statement. E.g.
> 
> Delete From cafeteria Where coke IN (SELECT type FROM pepsi).
> 
> Now imagine that the table cafeteria and pepsi are created using different
> storage engines. One storage engine does not know from the other.
> Especially not the data in it. Therfore the storage engine is told to
> simply delete the row containing the data in the bufer. If there is more
> than one row than the delete_row function is called multiple times untill
> all rows where passed through the delete_row function.

Hi!

But, by this logic, then statement-based replication wouldn't make 
sense, since the storage engine on the master and slave can be 
different, no?

In other words, why was this method chosen for the federated handler, 
but not for the replication writer?

Cheers!

jay
Thread
Rationale behind FEDERATED engine queriesGiuseppe Maxia19 Jun
  • Re: Rationale behind FEDERATED engine queriesPeter B. Volk19 Jun
    • Re: Rationale behind FEDERATED engine queriesJay Pipes19 Jun
      • Re: Rationale behind FEDERATED engine queriesBaron Schwartz19 Jun
        • Re: Rationale behind FEDERATED engine queriesPeter B. Volk19 Jun
          • Re: Rationale behind FEDERATED engine queriesEric Prud'hommeaux19 Jun
  • Re: Rationale behind FEDERATED engine queriesPhilip Stoev23 Jun