it's the remote InnoDB tables being accessed by a federated table that handles the transactions.
a Federated table is used if you want to avoid using table replication across multiple servers since the remote table can also be represented using a federated engine on a single machine thus making it transparent to the application (i.e. DB read-only report-generation app) regardless where the data is stored. but if the app is heavy on queries, i think the performance would be much better if all the data are stored locally via database replication. On 10/3/07, Orlando Andico <[EMAIL PROTECTED]> wrote: > > I just had a quick look at the federated table type. A few caveats: > > 1) Transactions are not supported > > 2) The remote table (there can be only one, it seems... someone > correct me if this is wrong) is accessed via MySQL Client API, > therefore speed issues galore > > 3) There is a 1:1 mapping between the local federated table, and the > remote table (which may be of any type) so you cannot "aggregate" > multiple remote tables onto a single local table. Thus, data > partitioning is STILL the responsibility of the application. > > With all of these limitations, I have trouble seeing the benefit of > this feature. >
_________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
