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