Thanks Mattias,
I didn't see your post until now, that's why I created another thread about this bug, sorry, I edited the other thread and cleared it.
Anyhow, all this seems a bit shaky to me, is there no other, more robust and consistent way to handle date ranges in MySQL partitioning? Will the doc explain this clearly? Why does the algorithm care about null/invalid dates? Invalid dates should be illegal to start with, and not allowed to be inserted in partitions divided by date ranges.
Mattias Jonsson Wrote:
-------------------------------------------------------
> Hi again,
>
> The fix should appear in the next service release,
> but I have no clue about any date.
>
> And yes that is one side effect with the fix, but
> it has a simple solution, create an NULL partition
> only for those dates which evaluates TO_DAYS(date)
> to NULL. That way it will have a minimum effect on
> performance.
>
>
> From
http://bugs.mysql.com/bug.php?id=20577
> [20 Aug 13:47] Mattias Jonsson
>
> When fixing this bug it will also change the
> pruning a bit:
> For range partitioning, it must also include the
> first partition (holding the NULL values)
> for queries using range search (i.e. <, >, <=, >=,
> BETWEEN) to be able to find 'virtual'
> dates like '2000-00-00'.
>
> This can affect performance for range partitioned
> tables on TO_DAYS() that have a large
> first partition. Work around is to create a first
> partition with VALUES LESS THAN (0).