Bug #5393 what is definition of "identical" in MERGE table description?
Submitted: 3 Sep 2004 16:50 Modified: 11 Aug 2005 14:41
Reporter: Timothy Smith Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:any OS:Any (any)
Assigned to: Documentation Team CPU Architecture:Any

[3 Sep 2004 16:50] Timothy Smith
Description:
This is what the manual currently says about the meaning of "identical":

> A MERGE table is a collection of identical MyISAM tables that can be
> used as one.

Which raises the question of what "identical" actually means, but...

> ``Identical'' means that all tables have identical column and index
> information.

that's circular. Most people would consider PACK_KEYS to be "index
information".  (And some who know the internals would wonder about
MAX_ROWS as well.)

> You can't merge tables in which the columns are listed in a different
> order,

fair enough.

> don't have exactly the same columns, or have the indexes in different
> order.

What about differing DEFAULT values? Or character sets?

And does "can't merge" mean the CREATE will fail, or it will work but
selecting from the table may produce bad data?

> However, any or all of the tables can be compressed with myisampack.
> See section 8.2 myisampack, the MySQL Compressed Read-only Table
> Generator.

> Differences in table options such as AVG_ROW_LENGTH, MAX_ROWS, or
> PACK_KEYS do not matter.

MAX_ROWS can change the size of the row pointers within the index.  The
docs should clarify if tables with differing index row pointer sizes can
be merged since that can be seen as part of "index information".

How to repeat:

n/a

Suggested fix:

Having said all the above I'd like to suggest an alternative approach.
Rather than try to list all the individual cans and can'ts for merge
tables it may be better to give a much clearer description of how
they're implemented. That would then naturally lead into the
consequences of the implementation where some of the above could be
discussed.

But having given a clear description of how merge tables are implemented
more users will be in a position to answer for themselves any issues not
directly covered by the docs.