Comments on: MySQL’s FEDERATED storage engine: Part 1

By: Xaprb

Xaprb — Mon, 29 Jan 2007 22:06:26 +0000

Peter, I'm not sure how the join buffer works, but from what I see it only "remember" the most recently fetched row in a join. When it has to join against 1, 1, 2 it fetches rows 1 and 2, but when it joins against 1, 2, 1 it fetches rows 1, 2, 1.

By: Xaprb

Xaprb — Mon, 29 Jan 2007 20:57:34 +0000

OK, now I agree with you -- if the remote connection is any type of DB server, yes the local server should decide. My approach to this was that it's a way to connect to other MySQL instances. Other servers is a much bigger topic. In that case an adapter is probably needed to make the most of whatever's on the other end of the connection; if it's MySQL, the current approach isn't as efficient as it could be.

By: Dmitry

Dmitry — Mon, 29 Jan 2007 19:15:30 +0000

“I also regard it as a bug that the local server thinks it knows better than the remote server how to execute any given query” – hm, afair, the original idea of federated tables was having remote connections to different db engines, might not even be mysql ones, so – yes, local server decides how/what ask from remote one, based on local table definition… or I’m way out of sync? :)

By: Peter Zaitsev

Peter Zaitsev — Mon, 29 Jan 2007 18:23:29 +0000

Great Article,

And I think you can report few bugs from it, such as killing connection causes next query to abort.

The comment about joining tables is interesting though - you can see each table is scanned only once which may be due to join buffer in MySQL or may be because of something else.

It would really be interesting to see how it works with large tables, how much data for example is buffered locally - so you do not run out of memory.

By: Xaprb

Xaprb — Mon, 29 Jan 2007 16:44:05 +0000

I disagree. I deliberately made the local table not have the same structure as the remote table so I could see what happened. I found some interesting edge cases, and yes I'd never do that in production. But I would characterize these "problems" as fun hacking, and there were only a few variations in behavior that I observed this way, certainly not 90%.

90% of the shortcomings I found are inherent to the engine itself and have nothing to do with table structure, in my opinion. I also regard it as a bug that the local server thinks it knows better than the remote server how to execute any given query. I think the storage engine should do a lot less optimization.