4 ms·

I think you're right but it's a bit out of scope. Hard to give generalizable advice around this I think. What we personally do in practice is put everything in

I think you're right but it's a bit out of scope. Hard to give generalizable advice around this I think. What we personally do in practice is put everything into a single time-series table with 11 columns. [1] 1: https://www.activityschema.com/ https://www.activityschema.com/

phibz 5y ago
Postgres has features that help these sort of OLAP type workflows. Things like: * partitioning your fact/aggregate tables (which was mentioned) * rolling up old data reducing granularity as data ages can help with record count and overall db size * PG triggers and stored procedures can be used to manage slowly changing dimensions * the hstore and json column types are super useful for implementing quazi-nosql storage along side traditional relational storage * window functions and CTEs (in 12) are great for writing analytical style queries * Implementing incremental loads with a staging/buffer table and possibly with plpgsql can really make connecting it all easier Not saying I didn't enjoy the article. It always makes me happy to see people realizing how suited PG can be to analytical workflows especially for small to medium workloads which represents most of what people want to do.