<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: MySQL&#8217;s FEDERATED storage engine: Part 1</title>
	<link>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/</link>
	<description>Stay curious!</description>
	<pubDate>Fri, 29 Aug 2008 19:58:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3574</link>
		<author>Xaprb</author>
		<pubDate>Mon, 29 Jan 2007 22:06:26 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3574</guid>
		<description>&lt;p&gt;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.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Peter, I&#8217;m not sure how the join buffer works, but from what I see it only &#8220;remember&#8221; 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>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3573</link>
		<author>Xaprb</author>
		<pubDate>Mon, 29 Jan 2007 20:57:34 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3573</guid>
		<description>&lt;p&gt;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.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>OK, now I agree with you &#8212; if the remote connection is any type of DB server, yes the local server should decide.  My approach to this was that it&#8217;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&#8217;s on the other end of the connection; if it&#8217;s MySQL, the current approach isn&#8217;t as efficient as it could be.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry</title>
		<link>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3571</link>
		<author>Dmitry</author>
		<pubDate>Mon, 29 Jan 2007 19:15:30 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3571</guid>
		<description>&lt;p&gt;"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? :)&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>&#8220;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&#8221; - 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&#8230; or I&#8217;m way out of sync? :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Zaitsev</title>
		<link>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3570</link>
		<author>Peter Zaitsev</author>
		<pubDate>Mon, 29 Jan 2007 18:23:29 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3570</guid>
		<description>&lt;p&gt;Great Article,&lt;/p&gt;

&lt;p&gt;And I think you can report few bugs from it, such as killing connection causes next query to abort. &lt;/p&gt;

&lt;p&gt;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. &lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<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>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3567</link>
		<author>Xaprb</author>
		<pubDate>Mon, 29 Jan 2007 16:44:05 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3567</guid>
		<description>&lt;p&gt;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%.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<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&#8217;d never do that in production.  But I would characterize these &#8220;problems&#8221; 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>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry</title>
		<link>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3566</link>
		<author>Dmitry</author>
		<pubDate>Mon, 29 Jan 2007 16:37:18 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/01/29/mysqls-federated-storage-engine-part-1/#comment-3566</guid>
		<description>&lt;p&gt;Looks like 90% of "problems" discovered so far were caused by not following the manual, which says to have same structure of local and remote tables ;)&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Looks like 90% of &#8220;problems&#8221; discovered so far were caused by not following the manual, which says to have same structure of local and remote tables ;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
