Konstantin Knizhnik wrote: > 3. Transpose of data and role of CS. > Let's look once again on Quote example above. Data is received in time > ascending order. But most queries require grouping it by symbol. So at some > stage we have to "transpose" data. To efficiently append data to timeseries > we need to buffer it somewhere and then use append range of values. In > Fujitsu approach two different representations of data are used: reader and > writer optimized. In IMCS approach, CS is just temporary projection of > normal PostgreSQL tables. So we do not need to worry about durability - it > is enforced by PostgreSQL. > > So the question is whether CS should be only storage for the data or just > copy (may be transient) of normal table?
Our original plan was that a CS was the primary storage of data, not a duplicate. However, after some discussion it became apparent that are several use cases that are better served by allowing redundant storage, i.e. having CSs that are just a reader-optimized copy of data that exists elsewhere. While I'm not a fan of that approach, I think it would be good to leave the door open for a future implementation of that. However, I think it'll bring interesting challenges to the optimizer side, so I'm not promising to work on it. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
