Most, if not all, storage engines need to store some data related to a physical
table, that is once per table, not per table instance (one physical table may be
opened many times yielding many handler instances of the same table). The
handler class provides storage area for engine private data per table instance,
but to store data common to all instances on the same physical table storage
engine needed until recently to maintain a hash by table name. Examples of this
approach are (in 5.1): ARCHIVE_SHARE, st_blackhole_share, EXAMPLE_SHARE,
TINA_SHARE, FEDERATED_SHARE, INNOBASE_SHARE, NDB_SHARE. Partitioning engine
doesn't use PARTITION_SHARE structure, but has it fields added directly to
TABLE_SHARE (yuck!).

This is code duplication (copied from one storage engine to another, ha_berkeley
started using this approach). And functionality duplication as SQL level already
has a shared structure like this - TABLE_SHARE. Storage engines should be able
to benefit from it.

THD structure has a dedicated pointer to storage engine private data - ha_data.
TABLE_SHARE should have it too, so that storage could use it.

Recently, as a bugfix for BUG#33479, TABLE_SHARE::ha_data was implemented.

The goal of this WorkLog task is to make use of it - partitioning data should be
moved from TABLE_SHARE to  PARTITION_SHARE. Archive, blackhole, example, tina,
federated, and ndb should drop the code that maintains the hash by name and
store the structure in TABLE_SHARE::ha_data instead.

Perhaps MyISAM, HEAP, MERGE, and Falcon could do the same (although these four
maintain the shared data differently - not copy-pasted from BDB engine - so
changing them would be not trivial).

NOTE: Currently the ha_data introduced in BUG#33479 is used by
ha_partitioning.cc, but this use must probably move to a specific auto_increment
area or a specific partitioning area, since it would not otherwise allow
partitioned tables handlers to use it. 

You must be logged in to tag this worklog

No Comments yet