I am playing around with mysql 5.6. Im especially interested in the possibility: A DATETIME or TIMESTAMP value can include a trailing fractional seconds part in up to microseconds (6 digits) precision.
What i would like is to partition a table using such a timestamp.
Example:
CREATE TABLE `VALUE_BIS` (
`TSTAMP` timestamp(3) NOT NULL,
`ATTRIBUTE_ID` int(11) NOT NULL,
`VAL` int(11) unsigned NOT NULL,
PRIMARY KEY (`ATTRIBUTE_ID`,`TSTAMP`)
) PARTITION BY RANGE (UNIX_TIMESTAMP(TSTAMP))
(PARTITION p_s18 VALUES LESS THAN (UNIX_TIMESTAMP('2012-09-18 00:00:00')),
PARTITION p_s19 VALUES LESS THAN (UNIX_TIMESTAMP('2012-09-19 00:00:00')),
PARTITION p_Max VALUES LESS THAN (UNIX_TIMESTAMP('2020-09-26 00:00:00' )));
==>ERROR 1491 (HY000): The PARTITION function returns the wrong type
*I think its normal as it returns unixtimestamp_seconds.microseconds which is not an integer*
If add the miliseconds like
PARTITION p_s18 VALUES LESS THAN (UNIX_TIMESTAMP('2012-09-18 00:00:00.000')
==> ERROR 1697 (HY000): VALUES value for partition 'p_s18' must have type INT
OK same story as before
If i change the definition of my tstamp column and do not use miliseconds
`TSTAMP` timestamp
==> It works just fine but i wont store my milliseconds and its not what i want.
Any idea?
MySQL still has some trouble partitioning tables with timestamps, like this one, which can cause a InnoDB crash. They've done a few changes in the behaviour of timestamp with fractional seconds in the past.
My first guess is that the way the fractual seconds are stored and used collides with the unix_timestamp. Therefore the partitioning can't be created properly (because wrong type) ... and therefore generate the error messages you encounter.
A workaround would be to add a second field which only contains the timestamp without fractual seconds and use this instead as your range identifier.
Either way, you should report the bug.