iBase.ru Forum

Была у меня простая табличка (smena) - время работы людей в системе:
userid integer
starttime timestamp
endtime timestamp

по обоим - индексы

и захотелось мне изжить у себя в системе timestamp'ы, жившие в ней со стародавних времен (для всех новых дел использую время в секундах с 2000 года, INTEGER)

добавил я для начала новые поля
starttm integer
endtm integer

сконвертировал данные, сохранив пока для совместимости и старые, переделал запросы и стал тестировать все ...

В процессе тестирования обнаружилось, что один из запросов стал с INTEGER выполняться медленее, чем с timestamp, и в статистике количество fetch радикально другое, при том, что планы - индентичные

вариант с integer:

select b.username,count(*)
from smena a,users b
where b.id=a.userid
and a.endtm >= 284688000
and a.starttm < 284774400
group by b.username order by b.username

PLAN SORT (JOIN (A INDEX (SMENA_STARTTM, SMENA_ENDTM), B INDEX (USER_ID)))

485583 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 161981 index, 0 seq.

с timetamp:

select b.username,count(*)
from smena a,users b
where b.id=a.userid
and a.endtime >= '2009-01-08'
and a.starttime < '2009-01-09'
group by b.username order by b.username

PLAN SORT (JOIN (A INDEX (SMENA_STARTTIME, SMENA_ENDTIME), B INDEX (USER_ID)))

2940 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 754 index, 0 seq.

На самом деле в оригинале запросы были чуть сложнее, но я их упростил для тестирования.

Имена индексов - это имятаблицы_имяполя

С татистику обновлял. Куда смотреть - не понимаю просто.

b/r делал?

kdv писал(а):b/r делал?

Нет.

При этом поле starttime накапливалось с начала существования БД, а starttm было добавлено недавно и заполнено большим пакетным конвертированием. Не знаю, влияет ли это на что-либо

по идее влияет. см. http://www.ibase.ru/devinfo/metaver.htm
т.е. в базе получается 2 набора версий - один старый без новых столбцов, и другой delta с добавленными столбцами (заполненными). Полными будут только вновь вставляемые записи.
идеальным было бы снятие полной статистики по БД до добавления столбцов, и после добавления и пакетного обновления - можно было бы хоть что-то рассмотреть. Но как я понимаю, теперь уже поздно. Впрочем, и с нынешней базы до b/r можно снять статистику ради интереса (gstat -a -r). Если таковая будет, присылать только в zip/rar на support@ibase.ru. Сюда статистику не втыкать - удалю.

Еще, конечно, могу выразить сомнение по поводу замены timestamp на integer, потому что в integer имеет смысл хранить или значения лет, месяцев и дней, или интервалы (в секундах, минутах). Но тут я не буду спорить или советовать, дело хозяйское.

Докладываю:
1. Не дожидаясь ответа я сделал b/r и проблема вылечилась
2. Копия БД есть и до b/r, и до добавления поля с конвертированием - у меня ежедневные автобекапы есть, причем сделанные с помоью copy, а не gbak Так что если интересно, то я могу снять статистику и прислать. Мне-то уже не актуально, хотя и любопытно, почему оно столь странно стало работать.
3. Я правильно понимаю, что для общего здоровья, сборки мусора и оптимизации индексов ежедневный b/r невреден? Мне в ночное время несложно его сделать

Насчет integer вместо timestamp - в него влезает (в секундах) 136 лет, если беззнаково. Если знаково - 68. Отсчет - от 2000 года. Столько я не проживу. Юниксоиды напрягаются в шутку - у них отчет от 1970 года, так что поговаривают про "проблему 2038 года"

При этом внутрях системы везде этот integer везде, а timestamp - сбоку припеку, один гемор от него. И создавать его надо при записи, и гемора с конвертирванием хватает после извлечения из БД. И место жрет.

если есть копия базы до и копия базы после добавления столбцов и обновления, то рекомендую самостоятельно изучить статистику от этих баз в IBAnalyst, если не хочется присылать

3. Я правильно понимаю, что для общего здоровья, сборки мусора и оптимизации индексов ежедневный b/r невреден? Мне в ночное время несложно его сделать

неправильно, особенно в отношении сборки мусора и "оптимизации" индексов. В том смысле, что restore это создание базы с нуля и заполнение ее данными из бэкапа. Т.е. в пересоздании базы данных я ничего плохого не вижу. Однако и необходимости это делать я тоже не вижу, т.к. это действие должно быть чем-то обосновано. Например, сильной фрагментацией БД за день, накоплением жуткого количества мусора из-за кривого управления транзакциями, и т.д.