List:Internals« Previous MessageNext Message »
From:Baron Schwartz Date:June 19 2007 12:41pm
Subject:Re: Rationale behind FEDERATED engine queries
View as plain text  
Jay Pipes wrote:
> 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?

I think this would still replicate correctly to a different storage engine, because of 
the LIMIT 1 added to each DELETE.

Baron
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