3 ms·

So how do you know what his/her use case is?

• greggyb 11y ago
  I don't know what it is, I only know that this comment prompted the deal killer comment: >>"Note. We currently don't support updating table using DELETE, and UPDATE commands. We also don't support single row inserts.". Just "COPY TO ..." or "INSERT INTO ... SELECT ..." is available it seems. >So that's a deal killer. Damn. This limitation is not a dealbreaker at all in a data warehousing environment, as I explained. Thus, I can assume that their use case is not data warehousing.
  • azinman2 11y ago
    Correct. I'm not data warehousing. I'm running a parse-like backend out of Postgres, where I have a lot of duplicated json keys. It would be great to have compression on the json to include this, while maintaining the other advantages of the json column store. However as they're hierarchical and there are many of them columns aren't appropriate (as far as I know but I haven't benchmarked some crazy dynamic solution... json certainly is easier to work with).
    • greggyb 11y ago
      I would keep an eye on the columnstore space. I know that Microsoft introduced read-only columnstore indices before introducing updateable ones, and their turnaround on it was 2 years - SQL Server 2012 to 2014. I'd use that as the outside end of an estimate for when the Postgres team will get updateable columnstore working.
      • ddorian43 11y ago
        Note, updatetable columnstore sucks everywhere, so I don't think so. It's only for OLAP, not OLTP (parse is oltp). What may help @azinman is group-compression (ex: bigger pages of rows and compress the whole page, where each json-key can be repeated multiple times in a page since each page may have multiple rows). This is what happens on tokudb,hbse,hypertable,cassandra.