<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Percona Server improvements on FromDual GmbH</title><link>https://www.fromdual.com/blog/mysql-shared-hosting-configuration/comment-161/</link><description>Recent content in Percona Server improvements on FromDual GmbH</description><generator>Hugo</generator><language>en-GB</language><managingEditor>oli.sennhauser@fromdual.com (Oli Sennhauser)</managingEditor><webMaster>oli.sennhauser@fromdual.com (Oli Sennhauser)</webMaster><copyright>© FromDual GmbH</copyright><lastBuildDate>Wed, 27 Jul 2011 15:10:29 +0200</lastBuildDate><atom:link href="https://www.fromdual.com/blog/mysql-shared-hosting-configuration/comment-161/index.xml" rel="self" type="application/rss+xml"/><item><title>Corresponding I_S table for Percona Server</title><link>https://www.fromdual.com/blog/warming-up-innodb-buffer-pool-during-start-up/comment-253/</link><pubDate>Wed, 27 Jul 2011 15:10:29 +0200</pubDate><author>oli.sennhauser@fromdual.com (Oli Sennhauser)</author><guid>https://www.fromdual.com/blog/warming-up-innodb-buffer-pool-during-start-up/comment-253/</guid><description>&lt;p&gt;Percona Server has had a buffer pool pages I_S table for a while, based on an earlier patch by Jeremy Cole or Eric Bergen, I think. However, I suspect that the Oracle implementation is likely to be safer. Some of the Percona I_S tables dealing with InnoDB internal information have had bugs, and I have become reluctant to use them on production systems. I am glad to see InnoDB providing their own implementation. Here is a link to the list of additional I_S tables provided in Percona Server: &lt;a href="http://www.percona.com/docs/wiki/percona-server:features:indexes:index_info_schema_tables"&gt;http://www.percona.com/docs/wiki/percona-server:features:indexes:index_info_schema_tables&lt;/a&gt;&lt;/p&gt;</description></item><item><title>HPM book documents this</title><link>https://www.fromdual.com/blog/mysql-query-cache-does-not-work-with-complex-queries-in-transactions/comment-227/</link><pubDate>Sun, 10 Jul 2011 23:53:10 +0200</pubDate><author>oli.sennhauser@fromdual.com (Oli Sennhauser)</author><guid>https://www.fromdual.com/blog/mysql-query-cache-does-not-work-with-complex-queries-in-transactions/comment-227/</guid><description>&lt;p&gt;I believe that we documented the query cache&amp;rsquo;s behavior, and the actual mechanism for it, in High Performance MySQL 2nd Edition. The blog post looks like FromDual has found an additional bug, though.&lt;/p&gt;
&lt;p&gt;I don&amp;rsquo;t think this is going to fundamentally change. The Query Cache is such a problem on so many servers that I can&amp;rsquo;t recommend it. If there is a 70% chance that it will help, and a 5% chance that it will cause complete system lockups, it has to be disabled.&lt;/p&gt;</description></item><item><title>Percona Server improvements</title><link>https://www.fromdual.com/blog/mysql-shared-hosting-configuration/comment-161/</link><pubDate>Fri, 22 Apr 2011 15:31:47 +0200</pubDate><author>oli.sennhauser@fromdual.com (Oli Sennhauser)</author><guid>https://www.fromdual.com/blog/mysql-shared-hosting-configuration/comment-161/</guid><description>&lt;p&gt;Percona Server has an option to limit amount of memory consumed by dictionary entries. This might be similar to what is in 5.6 from Oracle; I have not looked at the 5.6 code yet. We created this feature specifically for hosting providers :-)&lt;/p&gt;
&lt;p&gt;There are a number of other improvements for shared hosting providers, too, such as &amp;ldquo;don&amp;rsquo;t crash the whole server when a single table gets a corruption&amp;rdquo; or &amp;ldquo;allow import/export of individual tables to another server&amp;rdquo;.&lt;/p&gt;</description></item></channel></rss>