Trouble getting partitions to make a difference in query time - mysql

Question

I'm just experimenting a bit with partitions with some dummy data, and am not having any luck optimizing my queries so far.
I downloaded a dataset from the Internet, which consists of a single table of measurements:
CREATE TABLE `partitioned_measures` (
`measure_timestamp` datetime NOT NULL,
`station_name` varchar(255) DEFAULT NULL,
`wind_mtsperhour` int(11) NOT NULL,
`windgust_mtsperhour` int(11) NOT NULL,
`windangle` int(3) NOT NULL,
`rain_mm` decimal(5,2) DEFAULT NULL,
`temperature_dht11` int(5) DEFAULT NULL,
`humidity_dht11` int(5) DEFAULT NULL,
`barometric_pressure` decimal(10,2) NOT NULL,
`barometric_temperature` decimal(10,0) NOT NULL,
`lux` decimal(7,2) DEFAULT NULL,
`is_plugged` tinyint(1) DEFAULT NULL,
`battery_level` int(3) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (TO_DAYS(measure_timestamp))
(PARTITION `slow` VALUES LESS THAN (736634) ENGINE = InnoDB,
PARTITION `fast` VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
Just as a learning exercise I wanted to try to partition the measurements by measure_timestamp (without help of indexing). Specifically, I thought it would be interesting to try and put the most recent month in a partition by itself. (I understand that it's best to have equally-sized partitions, but I just wanted to experiment)
I used the following command to add the partition (Note that the dataset ends in Dec of 2016, and the vast majority of the datapoints are in prior months):
ALTER TABLE partitioned_measures
PARTITION BY RANGE(TO_DAYS(measure_timestamp)) (
PARTITION slow VALUES LESS THAN(TO_DAYS('2016-12-01')),
PARTITION fast VALUES LESS THAN (MAXVALUE)
);
To query, I'm looking at all entries from the 2nd and onward (just to be sure that I'm only looking in the latest partition):
select SQL_NO_CACHE COUNT(*) FROM partitioned_measures
WHERE measure_timestamp >= '2016-12-02'
AND DAYOFWEEK(measure_timestamp) = 1;
When I add an EXPLAIN to the front of that, I get the following:
+----+-------------+----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| 1 | SIMPLE | partitioned_measures | slow,fast | ALL | NULL | NULL | NULL | NULL | 1835458 | 33.33 | Using where |
+----+-------------+----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
But the query time is about the same as it was before the partition (~1.6 seconds). I've never used partitions before so I feel like there's something conceptual that I'm missing.

Answer 1

Tricky but i found a working solution or should i say a workaround, it seams to be a MySQL bug?
ALTER TABLE partitioned_measures
PARTITION BY RANGE COLUMNS(measure_timestamp) (
PARTITION slow VALUES LESS THAN('2016-12-01'),
PARTITION fast VALUES LESS THAN(MAXVALUE)
);
see demo which does use Partition Pruning correctly
i noticed that syntax here
I still find it wierd the partioning puning does not work correct, with
ALTER TABLE partitioned_measures
PARTITION BY RANGE(TO_DAYS(measure_timestamp)) (
PARTITION slow VALUES LESS THAN(TO_DAYS('2016-12-01')),
PARTITION fast VALUES LESS THAN (MAXVALUE)
);
MySQL 5.7 should be able to do the Partition Pruning which TO_DAYS() just fine
Pruning can also be applied for tables partitioned on a DATE or
DATETIME column when the partitioning expression uses the YEAR() or
TO_DAYS() function. In addition, in MySQL 5.7
source
see demo which does not use Partition Pruning correct, i've tryed alot to get it working all methods failed which i could think off.

Answer 2

The explanation:
It did do the pruning you requested, but it added the first partition. Why? Because there is where bad dates are put.
The workaround is to have a bogus first partition:
/*!50100 PARTITION BY RANGE (TO_DAYS(measure_timestamp))
({ARTITION bogus VALUES LESS THAN (0) ENGINE = InnoDB, -- any small value
PARTITION `slow` VALUES LESS THAN (736634) ENGINE = InnoDB,
PARTITION `fast` VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
Reference is buried in https://dev.mysql.com/doc/refman/5.7/en/partitioning-handling-nulls.html
If you had more than a trivial number of partitions you might have been more obvious that it picked the desired partition, plus always the first.
With rare exceptions, partitioning does not provide better performance than you can get from a non-partitioned table with a suitable index. In this case, INDEX(measure_timestamp). (Or a virtual column with INDEX(dow, measure_timestamp).)