Re: timestamp, datetime as default value as current_timestamp [PARTITION]

[Mannoj Kumar]

Actually I just tested in 5.6.6 it works - timestamp doesn't work whereas datetime datatype with default CURRENT_TIMESTAMP WORKS!! Any workaround if I can still stay in 5.5? And just add a plugin for this functionality?

Yes Aftab , I currently stay in 5.5.25 . And its gona use single row insert and updates.

| contentq | CREATE TABLE `contentq` (
`idcontent` bigint(120) unsigned NOT NULL AUTO_INCREMENT,
`keyvendor` varchar(32) DEFAULT '0',
`msisdn` varchar(16) DEFAULT NULL,
`cli` varchar(16) DEFAULT NULL,
`message` text,
`udh` text,
`priority` int(10) unsigned DEFAULT '1',
`recorddate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`callback_url` text,
`transactionid` varchar(256) DEFAULT NULL,
`status` tinyint(4) DEFAULT '0',
PRIMARY KEY (`idcontent`),
KEY `PriorityIndex` (`status`,`priority`,`keyvendor`),
KEY `NewIndex1` (`keyvendor`,`status`),
KEY `idx_contentq_msisdn` (`msisdn`)
) ENGINE=InnoDB AUTO_INCREMENT=72063009 DEFAULT CHARSET=latin1 |
+----------+----------------------------------------------------------------------
1 row in set (0.00 sec)

mysql> show table status;
+--------------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+---------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment |
+--------------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+---------+
| contentq | InnoDB | 10 | Compact | 69294495 | 352 | 24445452288 | 0 | 12182355968 | 8388608 | 72063009 | 2012-08-27 21:38:34 | NULL | NULL | latin1_swedish_ci | NULL


Regarding purging, application team is fine to keep 6months latest data on the table contentq. So I have planned to keep retention period of 7months of latest data by keeping each month data in each partitions. And then rotate the 8th month partition to a new table in the same database and dropping the oldest 8thpartition partition and add newer +1 next month partition. This is my approach. As each partition might hold one month data of abt avg ranging is 50million records. Is that is feasible?

Below is the template for the partition that I have succeeded in 5.6.6

mysql> CREATE TABLE `contentq_par` (
-> `idcontent` bigint(120) unsigned NOT NULL AUTO_INCREMENT,
-> `keyvendor` varchar(32) DEFAULT '0',
-> `msisdn` varchar(16) DEFAULT NULL,
-> `cli` varchar(16) DEFAULT NULL,
-> `message` text,
-> `udh` text,
-> `priority` int(10) unsigned DEFAULT '1',
-> `recorddate` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
-> `callback_url` text,
-> `transactionid` varchar(256) DEFAULT NULL,
-> `status` tinyint(4) DEFAULT '0',
-> PRIMARY KEY (`idcontent`,`recorddate`),
-> KEY `PriorityIndex` (`status`,`priority`,`keyvendor`),
-> KEY `NewIndex1` (`keyvendor`,`status`),
-> KEY `idx_contentq_msisdn` (`msisdn`)
-> ) ENGINE=INNODB
-> PARTITION BY RANGE( TO_DAYS(recorddate) ) (
-> PARTITION rx201201 VALUES LESS THAN( TO_DAYS('2012-01-01 00:00:00') ),
-> PARTITION rx201202 VALUES LESS THAN( TO_DAYS('2012-02-01 00:00:00') ),
-> PARTITION rx201203 VALUES LESS THAN( TO_DAYS('2012-03-01 00:00:00') ),
-> PARTITION rx201204 VALUES LESS THAN( TO_DAYS('2012-04-01 00:00:00') ),
-> PARTITION rx201205 VALUES LESS THAN( TO_DAYS('2012-05-01 00:00:00') ),
-> PARTITION rx201206 VALUES LESS THAN( TO_DAYS('2012-06-01 00:00:00') ),
-> PARTITION rx201207 VALUES LESS THAN( TO_DAYS('2012-07-01 00:00:00') ),
-> PARTITION rx201208 VALUES LESS THAN( TO_DAYS('2012-08-01 00:00:00') ),
-> PARTITION rx201209 VALUES LESS THAN( TO_DAYS('2012-09-01 00:00:00') ),
-> PARTITION rxMORES VALUES LESS THAN (MAXVALUE) );
Query OK, 0 rows affected (0.07 sec)



Edited 2 time(s). Last edit at 08/29/2012 04:39AM by Mannoj Kumar.