On 10.04.2019 10:25, Heikki Linnakangas wrote:
On 10/04/2019 09:29, Amit Kapila wrote:
On Tue, Apr 9, 2019 at 5:57 AM Ashwin Agrawal <aagra...@pivotal.io>
wrote:
Row store
---------
The tuples are stored one after another, sorted by TID. For each
tuple, we store its 48-bit TID, a undo record pointer, and the actual
tuple data uncompressed.
Storing undo record pointer with each tuple can take quite a lot of
space in cases where you can't compress them.
Yeah. This does depend on compression to eliminate the unused fields
quite heavily at the moment. But you could have a flag in the header
to indicate "no undo pointer needed", and just leave it out, when it's
needed.
Have you thought how will you implement the multi-locker scheme in
this design? In zheap, we have used undo for the same and it is easy
to imagine when you have separate transaction slots for each
transaction. I am not sure how will you implement the same here.
I've been thinking that the undo record would store all the XIDs
involved. So if there are multiple lockers, the UNDO record would
store a list of XIDs. Alternatively, I suppose you could store
multiple UNDO pointers for the same tuple.
- Heikki
I also a little bit confused about UNDO records and MVCC support in
Zedstore. Actually columnar store is mostly needed for analytic for
read-only or append-only data. One of the disadvantages of Postgres is
quite larger per-record space overhead caused by MVCC.
It may be critical if you want to store huge timeseries with relatively
small number of columns (like measurements of some sensor).
It will be nice to have storage format which reduce this overhead when
it is not needed (data is not updated).
Right now, even without UNFO pages, size of zedstore is larger than size
of original Postgres table.
It seems to be very strange.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
