|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день. Есть табличка логов, разбитая по дням : PARTITION BY LINEAR HASH (LogDay) PARTITIONS 366
Так вот, заметил интересный эффект: выборка нужных партиций при запросе с условием where LogDay between dayofyear(now())-10 and dayofyear(now())-1 работает нормально.
Но стоит увеличить диапазон дней более 10, pruning перестает работать и юзает все партиции! Например, between dayofyear(now())-11 and dayofyear(now())-1 или between dayofyear(now())-10 and dayofyear(now()) и т.д.
В документации такого поведения не обнаружил. Говорится, что оптимизация должна работать в случае hash - партиций по целочисленным полям, как в моем случае(`LogDay` smallint(6) NOT NULL).
Версия сервера: 5.1.28-rc
Почему так происходит и как лечить, если возможно?
Неактивен
Да, очень интересное поведение. Похоже, в алгоритм вшито это число. На 5.1.30 происходит то же
самое.
Уже описанных багов на bugs.mysql.com не нашел, попробуйте запостить свою.
Ну и, конечно же, обновитесь до .30 версии. Хоть и не полечит проблему, но все-таки это будет первое,
что они попросят Вас сделать.
Неактивен
Запостил баг (http://bugs.mysql.com/bug.php?id=42210)
Действительно, задано константой при компиляции.
Пока хотят поднять лимит до 32, а если повезет, сделают настраиваемым параметром 
Неактивен
[26 Jun 2008 17:05] Sergey Petrunia
At the moment we have no intent to fix this in 5.1
We intend to fix this issue in MySQL 6.0 by
- introducing a tunable server parameter (most likely)
- changing the default from 10 to some greater value (likely)
Не похоже, что в ближайшее время 
Неактивен
