2 ms·

Thanks. So if I understand correctly, this is basically like ignoring all the other columns (that you're not interested in)? And do you run them in conjunction

Thanks. So if I understand correctly, this is basically like ignoring all the other columns (that you're not interested in)? And do you run them in conjunction with your existing Postgres, install it as a plugin, or switch your entire db to something like Hydra?

ako 3y ago
Usually you choose the type of database based on your use case. Reporting databases like data warehouses, benefit from using a column oriented database, whereas transactional use cases use a row oriented database. Modern databases allow you to choose per table.
beagle3 3y ago
Yes, the downside being that if you need all the columns of one specific record (row), it will be spread over many column blocks. As a rule of the thumb, if most of your queries are aggregations over few columns of many records (OLAP), column based would be a better choice - whereas if you need to access every column/field of a small number of records (OLTP), record/row based would be a better choice.
adammarples 3y ago
And in addition, each column, or even partition of a column, can store statistics about itself like min max avg count etc. That way if you look up max(column) you only have to read the meta data on the partitions on that column, it's very fast. And for analytics this is pretty common.