MySQL Forums
Forum List  »  Partitioning

Re: HOW TO: PARTITION USING "TIMESTAMP"
Posted by: Jin No Kim
Date: March 20, 2007 05:28AM

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

Options: ReplyQuote


Subject
Views
Written By
Posted
3632
January 19, 2007 06:55AM
Re: HOW TO: PARTITION USING "TIMESTAMP"
2979
March 20, 2007 05:28AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.