Description
Describe the bug
Docs unclear about behavior if row timestamps don't match insert/update time
What do the docs say now?
The docs say things like "The policy in this example ensures that all the data in the continuous aggregate is up to date with the hypertable except for anything written in the last hour."
Which of the two possibilities does this mean?
- The
INSERT/UPDATEwas literally performed within the last hour, regardless of the row timestamps? or - The timestamp on the row is within the last hour, regardless of
INSERT/UPDATEtime?
I don't see any evidence that Postgres system columns track insert/update timestamps or that Timescale creates internal columns for this, so I think this statement isn't correct if data timestamped way in the future or the past is inserted?
What should the docs say?
"The policy in this example ensures that all the data in the continuous aggregate is up to date with the hypertable except for anything timestamped in the last hour (that is, the value you have provided in your timestamp index column is in the last hour)"
Page affected
/use-timescale/latest/continuous-aggregates/refresh-policies/
Subject matter expert (SME)
Screenshots
[Attach images of screenshots showing the bug]
Any further info
A lot of Timescale's design seems to be oriented around inserting data in realtime as it's acquired, but this is a massive assumption, so the docs should have a lot of warnings about what happens when this is not the case. I'm guessing importing historical data is a reasonably common use case
Contributing to documentation
We welcome documentation contributions! For guidelines, see the contributing guide.