On 11th June 2013, Markus Wanner wrote: > >> Agreed. Postgres-R uses a CommitOrderId, which is very similar in > >> concept, for example. > > > > Do you think having this snapshot scheme would be helpful for > Postgres-R? > > Yeah, it could help to reduce patch size, after a rewrite to use such a > CSN. > > >> Or why do you need to tell apart aborted from in-progress > >> transactions by CSN? > > > > I need to detect aborted transactions so they can be discared during > > the eviction process, otherwise the sparse array will fill up. They > > could also be filtered out by cross-referencing uncommitted slots > with > > the procarray. Having the abort case do some additional work to make > > xid assigment cheaper looks like a good tradeoff. > > I see. > > >>> Sparse buffer needs to be at least big enough to fit CSN slots for > >>> the xids of all active transactions and non-overflowed > >>> subtransactions. At the current level PGPROC_MAX_CACHED_SUBXIDS=64, > >>> the minimum comes out at 16 bytes * (64 + 1) slots * 100 = > backends > >>> = 101.6KB per buffer, or 203KB total in the default configuration. > >> > >> A CSN is 8 bytes, the XID 4, resulting in 12 bytes per slot. So I > >> guess the given 16 bytes includes alignment to 8 byte boundaries. > Sounds good. > > > > 8 byte alignment for CSNs is needed for atomic if not something else. > > Oh, right, atomic writes. > > > I think the size could be cut in half by using a base value for CSNs > > if we assume that no xid is active for longer than 2B transactions as > > is currently the case. I didn't want to include the complication in > > the first iteration, so I didn't verify if that would have any > > gotchas. > > In Postgres-R, I effectively used a 32-bit order id which wraps around. > > In this case, I guess adjusting the base value will get tricky. > Wrapping could probably be used as well, instead. > > > The number of times each cache line can be invalidated is bounded by > > 8. > > Hm.. good point. >
We are also planning to implement CSN based snapshot. So I am curious to know whether any further development is happening on this. If not then what is the reason? Am I missing something? Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers