~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to docs/indexes.rst

* Completes the blueprint for splitting the XA Resource Manager
  API from the storage engine API:

We add a new plugin::XaResourceManager abstract interface class
which exposes the X/Open XA distributed transaction protocol for
resource managers.

We add a new plugin::MonitoredInTransaction base class from
which all plugins that need monitored by Drizzle's transaction
manager (drizzled::TransactionServices component) derive.

All plugin::StorageEngine's now derive from plugin::MonitoredInTransaction
since all storage engines a monitored by the transaction manager
and the Session keeps a "slot" available for keeping the engine's
per-session data state.  In a future patch, the transaction log's
XaApplier plugin will also derive from MonitoredInTransaction, as
the transaction log, in XA mode, is also monitored by Drizzle's
transaction manager and automatically enlisted in XA transactions.

* Updates all documentation in /drizzled/transaction_services.cc
  to accurately reflect Drizzle's new transaction management
  process and explicit transaction and statement boundaries.

* Kills off dead code:

  binlog_format_names
  ha_init()
  total_ha, total_ha_2pc (no longer necessary, as the above-mentioned
  abstract base classes provide all of this functionality)
  StorageEngine::slot (now plugin::MonitoredInTransaction::getId())
  TransactionalStorageEngine::two_phase_commit (same as above)

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
Indexes
2
 
=======
3
 
 
4
 
To quote wikipedia, "An index is a data structure that improves the
5
 
speed of data retrieval operations on a database table at the cost of slower
6
 
writes and increased storage space. Indexes can be created using one or more
7
 
columns of a database table, providing the basis for both rapid random
8
 
lookups and efficient access of ordered records. The disk space required to
9
 
store the index is typically less than that required by the table (since
10
 
indexes usually contain only the key-fields according to which the table is
11
 
to be arranged, and exclude all the other details in the table), yielding
12
 
the possibility to store indexes in memory for a table whose data is too
13
 
large to store in memory."
14
 
 
15
 
 
16
 
.. toctree::
17
 
   :maxdepth: 2
18
 
 
19
 
   create_index
20
 
   drop_index