<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Reasons to use InnoDB Plugin</title>
	<atom:link href="http://code.openark.org/blog/mysql/reasons-to-use-innodb-plugin/feed" rel="self" type="application/rss+xml" />
	<link>http://code.openark.org/blog/mysql/reasons-to-use-innodb-plugin</link>
	<description>Blog by Shlomi Noach</description>
	<lastBuildDate>Wed, 01 Feb 2012 20:47:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: shlomi</title>
		<link>http://code.openark.org/blog/mysql/reasons-to-use-innodb-plugin/comment-page-1#comment-3109</link>
		<dc:creator>shlomi</dc:creator>
		<pubDate>Mon, 10 Aug 2009 18:10:09 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=951#comment-3109</guid>
		<description>@Sheeri,

As far as I understand, indexes on text columns / BLOBs will be less fragmented internally, as long text data is stored off page (instead of allocating up to 768 bytes per value). This means more data per page, which, apart from less total number of pages, also leads to less splitting, and hence less fragmentation.

I&#039;m not sure how the off-page texts/BLOBs are fragmented.

Otherwise I have no actual information about this. No doubt Vadim (Percona) can tell us all about it.

Regards</description>
		<content:encoded><![CDATA[<p>@Sheeri,</p>
<p>As far as I understand, indexes on text columns / BLOBs will be less fragmented internally, as long text data is stored off page (instead of allocating up to 768 bytes per value). This means more data per page, which, apart from less total number of pages, also leads to less splitting, and hence less fragmentation.</p>
<p>I'm not sure how the off-page texts/BLOBs are fragmented.</p>
<p>Otherwise I have no actual information about this. No doubt Vadim (Percona) can tell us all about it.</p>
<p>Regards</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sheeri</title>
		<link>http://code.openark.org/blog/mysql/reasons-to-use-innodb-plugin/comment-page-1#comment-3108</link>
		<dc:creator>Sheeri</dc:creator>
		<pubDate>Mon, 10 Aug 2009 17:16:32 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=951#comment-3108</guid>
		<description>How does Barracuda handle fragmentation?  same as InnoDB?</description>
		<content:encoded><![CDATA[<p>How does Barracuda handle fragmentation?  same as InnoDB?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Log Buffer #157: a Carnival of the Vanities for DBAs &#124; Pythian Group Blog</title>
		<link>http://code.openark.org/blog/mysql/reasons-to-use-innodb-plugin/comment-page-1#comment-3051</link>
		<dc:creator>Log Buffer #157: a Carnival of the Vanities for DBAs &#124; Pythian Group Blog</dc:creator>
		<pubDate>Fri, 07 Aug 2009 16:53:05 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=951#comment-3051</guid>
		<description>[...] Noach stepped up with reasons to use InnoDB plug-in. &#8220;The plugin is a drop-in replacement for “normal” InnoDB tables; enabling many new [...]</description>
		<content:encoded><![CDATA[<p>[...] Noach stepped up with reasons to use InnoDB plug-in. &#8220;The plugin is a drop-in replacement for “normal” InnoDB tables; enabling many new [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark R</title>
		<link>http://code.openark.org/blog/mysql/reasons-to-use-innodb-plugin/comment-page-1#comment-2963</link>
		<dc:creator>Mark R</dc:creator>
		<pubDate>Mon, 03 Aug 2009 10:11:21 +0000</pubDate>
		<guid isPermaLink="false">http://code.openark.org/blog/?p=951#comment-2963</guid>
		<description>Yes, compression is the main one; I think fast index creation (and faster index dropping) might be useful in some cases, for example, if you have data partitioned by day and want to create more indexes on old days&#039; data for efficient searching, but only after the day is over (and the data aren&#039;t as &quot;hot&quot; any more so you don&#039;t really want to do table scans)</description>
		<content:encoded><![CDATA[<p>Yes, compression is the main one; I think fast index creation (and faster index dropping) might be useful in some cases, for example, if you have data partitioned by day and want to create more indexes on old days' data for efficient searching, but only after the day is over (and the data aren't as "hot" any more so you don't really want to do table scans)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

