Comments on: MySQL’s FEDERATED storage engine: Part 1 http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/ Stay curious! Thu, 09 Feb 2012 09:56:43 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Xaprb http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3574 Xaprb Mon, 29 Jan 2007 22:06:26 +0000 http://www.xaprb.com/blog/?p=296#comment-3574 <p>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.</p> 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 http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3573 Xaprb Mon, 29 Jan 2007 20:57:34 +0000 http://www.xaprb.com/blog/?p=296#comment-3573 <p>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.</p> 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 http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3571 Dmitry Mon, 29 Jan 2007 19:15:30 +0000 http://www.xaprb.com/blog/?p=296#comment-3571 <p>"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? :)</p> “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 http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3570 Peter Zaitsev Mon, 29 Jan 2007 18:23:29 +0000 http://www.xaprb.com/blog/?p=296#comment-3570 <p>Great Article,</p> <p>And I think you can report few bugs from it, such as killing connection causes next query to abort. </p> <p>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. </p> <p>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.</p> 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 http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3567 Xaprb Mon, 29 Jan 2007 16:44:05 +0000 http://www.xaprb.com/blog/?p=296#comment-3567 <p>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%.</p> <p>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.</p> 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.

]]>