Hacker News Reader

Comment by akulkarni | Hacker News Reader

It's a bit more complicated than that. At a high-level: views + auto-sizing of tables + fast insert path + time-based query optimizations + (upcoming) cluster support (+ more).

We do not currently support bitemporal constructs.

What's an example of a temporal foreign key query that you need?

View on HN

If you have two logical views of information, say people and their jobs. Imagine the attributes of people change over time. Also the attributes of their jobs change over time. It's possible to delete a person record from the person table. What if a Job record references that person and it intersects with the period of time that has been removed from the person. Suddenly the data would be nonsensical. I don't ask this to be obtuse, but when I see joins supported in sql on a time oriented database, I assume some position is being taken on this.

Basically, does the database have an opinion on time oriented data consistency?

Ah, sounds like you are again thinking about bitemporal reasoning over relational data.

We are not really built for that use case. Instead of focusing on fundamentally relational data such as people or jobs (which you are free to store alongside our stuff, using plain postgres functionality), we store event or metrics data. This data can be easily joined against the relational data (e.g., using a person_id stored in both event and relational tables).

I reread 'managing time in relational databases' like 3 times one summer and now every time I mess with time in databases I have a heart attack.

That makes sense, thanks for answering ;)

Reply on news.ycombinator.com