Jon Stephens Wrote:
-------------------------------------------------------
>
> As I think I've said to you before: There is no
> particular advantage to using TIMESTAMP. Use
> DATETIME.
>
I am assuming that by "no particular advantage" you are able to discount the
additional I/O 8bytes a row adds across a 25 billion row data warehouse with 2
date fields/row. This also discounts the index savings when one of the TIMESTAMP
columns is indexed.
From experience every bit counts when you go large - you literally look for ways
to store your data as efficiently as the DB will allow. This is part of the
reason we chose MySQL over Oracle for this project - the variety of data types
available in MySQL allowed us to select each column data type to be as small as
possible, making the DB as efficient as possible.
MySQL Documentation on data storage requirements for 5.0 and 5.1:
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html
Are there specific design problems preventing range partitioning based upon
timestamps, or was it just deemed unnecessary? I have not been able to
experiment with partitioning to the extent I'd like, but the extra 200G of
storage DATETIME requires in my application and the 3~4 weeks of converting old
data certainly makes it less appealing than MyISAM+Merge (the existing
production solution).
I've been lurking here for the last few months because work projects and family
have kept me away and a reload of the home system required I re-register.
-JNK