2017-02-23 136 views
0

Мы имеем дело с агрегированными данными временных рядов, агрегированными с фиксированным типом периода, например. недель со вторника по среду.Использовать daterange как ключ в Postgres для данных агрегированных временных рядов

Было ли это "плохой практикой" использовать Postgres daterange введите key для просмотра этой информации? (Вместо того, чтобы, например, имеющей "PeriodID" -Key, который определяет эту DateRange, а затем присоединиться в календарном измерении, чтобы определить, что DateRange.)

В мой взгляд, это было бы просто излишним с отдельным "PeriodID" как daterange имеет очень четкое (и в нашей постановке оно будет уникальным для каждого наблюдения).

Есть: соображения

  • производительности?
  • Другие соображения?
+0

Я думаю, что это больше зависит от того, как вы собираетесь его использовать позже. Обычно вы просто создаете индекс на отметке времени и сравниваете его с ts. Если вам нужен диапазон, вы можете просто генерировать_серии с 7-дневным периодом. –

ответ

1

На абстрактном уровне tstzrange будет идеальным представлением для такого объединения.

Проблема, которую следует учитывать, заключается в том, как вы будете запрашивать данные и как эффективно использовать индексы.

Если вы хотите индексировать “ ” содержит оператор @> или “ ” перекрывает оператор &&, вы не можете использовать B-дерева индексы, только GIST и SP-GiST индексов (см the documentation). Вы должны были бы сравнить это, но есть вероятность, что использование такого индекса будет медленнее, если использовать индекс B-дерева в столбце timestamptz. Индекс может также использовать больше места.

Простой способ использовать timestamptz с индексом В-дерева будет хранить нижний конец диапазона и запрос следующим образом:

... WHERE weekstart <= atimestamp 
     AND weekstart > atimestamp - INTERVAL '1 week' 

Или запросить для перекрытия интервала:

... WHERE weekstart <= endtimestamp 
     AND weekstart > starttimestamp - INTERVAL '1 week'