drev[quot Кот Матроскин]Срез - "агрегат типа "сумма последнего платежа"", т.е., грубо, функция не SUM, а MAX.
LAST_VALUE а не MAX тогда уж
Дополнительный выигрыш во времени доступа (но за счет дискового пространства естественно) можно получить, если использовать секционирование по времени и хранить промежуточные значения. Скажем на 0:00 каждых суток, если размер секции - сутки. Тогда даже если требуется значение на какое-то определенное время, то поиск будет происходить все равно с первичным отбором по условию date_column = :some_date, а потом уже поиск внутри результирующего набора. В этом случае всегда будет проходить поиск только по одной секции, чего принципиально невозможно добиться без хранения промежуточных значений. А значит можно будет эффективно использовать локально секционированные индексы.
Как вариант для уменьшения объема промежуточных данных - добавлять только одно промежуточное значение на последнюю секунду секции, и только в том случае если в секцию не попало ни одного нового значения переменной.

drev TiG drev[quot Кот Матроскин]Срез - "агрегат типа "сумма последнего платежа"", т.е., грубо , функция не SUM, а MAX.
LAST_VALUE а не MAX тогда уж
Дополнительный выигрыш во времени доступа (но за счет дискового пространства естественно) можно получить, если использовать секционирование по времени и хранить промежуточные значения. Скажем на 0:00 каждых суток, если размер секции - сутки. Тогда даже если требуется значение на какое-то определенное время, то поиск будет происходить все равно с первичным отбором по условию date_column = :some_date, а потом уже поиск внутри результирующего набора. В этом случае всегда будет проходить поиск только по одной секции, чего принципиально невозможно добиться без хранения промежуточных значений. А значит можно будет эффективно использовать локально секционированные индексы.
Как вариант для уменьшения объема промежуточных данных - добавлять только одно промежуточное значение на последнюю секунду секции, и только в том случае если в секцию не попало ни одного нового значения переменной .


1. Вы на слово " грубо " обратили внимание?:) Кстати, MAX как агрегатная функция более известна:) Поэтому, вероятность, что меня поймут была выше.

2. Вариант секционирования по времени, а не по количеству новых записей имеет главный недостаток - непредсказуемость.

3. Фраза, выделеная синим , на мой взгляд, противоречит концепции.
1. ок :)
2. ... если поток данных сильно неравномерный. Но зато упрощается логика и лучше поддается оптимизации. Как вариант - динамический размер секции (тут надо либо хитрить при загрузке, либо при нарезке секций на базе прошлой статистики определять оптимальный размер секции в зависимости от времени). Или использование суррогатного ключа секционирования, одинаковые диапазоны которого (соответствующие размеру секции) мапятся на временные интервалы разной длины, но содержащие примерно одинаковое количество записей (в этом случае необходимо дополнительно удостовериться что все значения с совпадающими временными метками получают одно и то же значение ключа секционирования + дополнительная логика определения значений ключей секционирования по заданной дате при выборке). Поэтому если есть возможность, то лучше все-таки остановиться на более простом варианте ;-)
3. да, думаю вы правы, поторопился я. Если оптимизировать выборку, то лучше добавлять для каждого показателя текущее значение на начало секции и при отборе выбирать данные от начала секции до нужной временной отметки, а уж из них - последнее значение.