Тут экспериментировал с архивацией списаний и формированием отчетов и заметил странность
Зачем то при формировании отчета за март у меня ворошилась архивная таблица за февраль. Все перепробовал пока не перевел INT значение даты в читаемый формат. Оказалось что если в отчете по трафику запросить данные с 01.03.210 00:00:00 по 01.04.210 00:00:00 то генериться запрос к базе начиная с (1267387200) int а это в свою очередь
to_timestamp
------------------------
2010-02-28 23:00:00+03
Оказалось так же что дата окончания такого отчета 2010-03-31 23:00:00+03
Это вообще как понимать? Или мне стоит создавать архивы с сдвигом на час чтобы при отчете за целый месяц не дергались лишние таблицы? А то они весят по 3 гига каждая, тяжко серверу такое ворочать из за одного часа.
Однако при запросе такого отчета для конкретного пользователя такого сдвига нету. Отсюда возникают коллизии при выставлении счетов.
Я использую PostgreSQL и последнюю стабильную сборку UTM5
p.s. Если кому интересно могу поделиться хранимой функцией на plpgsql для создания архивов списаний.
Формирование отчета пот трафику за месяц
Эксперименты показали, что при запросе за предыдущие периоды не учитывается, что тогда у нас был другой часовой пояс. т.к. архивацию я выполнял средствами postgres и даты начала и конца месяца выбирал тоже его родными средствами, то у меня получилось все учтено, не плохо было бы учитывать это при составлении запросов внутри UTM или где они там составляются...?
SELECT * from archives order by archive_id desc limit 14;
id | archive_id | table_type | table_name | start_date | end_date
----+------------+------------+--------------------------------------------+------------+------------
91 | 11 | 7 | payment_transactions_2010_4 | 1267390800 | 1270065599
85 | 11 | 1 | discount_transactions_all_2010_4 | 1267390800 | 1270065599
86 | 11 | 2 | discount_transactions_iptraffic_all_2010_4 | 1267390800 | 1270065599
87 | 11 | 3 | tel_sessions_log_2010_4 | 1267390800 | 1270065599
88 | 11 | 4 | tel_sessions_detail_2010_4 | 1267390800 | 1270065599
89 | 11 | 5 | dhs_sessions_log_2010_4 | 1267390800 | 1270065599
90 | 11 | 6 | dhs_sessions_detail_2010_4 | 1267390800 | 1270065599
78 | 10 | 1 | discount_transactions_all_2010_3 | 1264971600 | 1267390799
84 | 10 | 7 | payment_transactions_2010_3 | 1264971600 | 1267390799
83 | 10 | 6 | dhs_sessions_detail_2010_3 | 1264971600 | 1267390799
82 | 10 | 5 | dhs_sessions_log_2010_3 | 1264971600 | 1267390799
81 | 10 | 4 | tel_sessions_detail_2010_3 | 1264971600 | 1267390799
80 | 10 | 3 | tel_sessions_log_2010_3 | 1264971600 | 1267390799
79 | 10 | 2 | discount_transactions_iptraffic_all_2010_3 | 1264971600 | 1267390799
SELECT * from archives order by archive_id desc limit 14;
id | archive_id | table_type | table_name | start_date | end_date
----+------------+------------+--------------------------------------------+------------+------------
91 | 11 | 7 | payment_transactions_2010_4 | 1267390800 | 1270065599
85 | 11 | 1 | discount_transactions_all_2010_4 | 1267390800 | 1270065599
86 | 11 | 2 | discount_transactions_iptraffic_all_2010_4 | 1267390800 | 1270065599
87 | 11 | 3 | tel_sessions_log_2010_4 | 1267390800 | 1270065599
88 | 11 | 4 | tel_sessions_detail_2010_4 | 1267390800 | 1270065599
89 | 11 | 5 | dhs_sessions_log_2010_4 | 1267390800 | 1270065599
90 | 11 | 6 | dhs_sessions_detail_2010_4 | 1267390800 | 1270065599
78 | 10 | 1 | discount_transactions_all_2010_3 | 1264971600 | 1267390799
84 | 10 | 7 | payment_transactions_2010_3 | 1264971600 | 1267390799
83 | 10 | 6 | dhs_sessions_detail_2010_3 | 1264971600 | 1267390799
82 | 10 | 5 | dhs_sessions_log_2010_3 | 1264971600 | 1267390799
81 | 10 | 4 | tel_sessions_detail_2010_3 | 1264971600 | 1267390799
80 | 10 | 3 | tel_sessions_log_2010_3 | 1264971600 | 1267390799
79 | 10 | 2 | discount_transactions_iptraffic_all_2010_3 | 1264971600 | 1267390799