Re: [HACKERS] Transaction system (proposal for 6.5)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Transaction system (proposal for 6.5) |
Дата | |
Msg-id | 199809210134.VAA15365@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Transaction system (proposal for 6.5) (Robson Miranda <rmiranda@rudah.com.br>) |
Ответы |
Re: [HACKERS] Transaction system (proposal for 6.5)
|
Список | pgsql-hackers |
> Hi... > > > I was thinking in a major rewrite of the PostrgreSQL transaction > system, in order to provide less tuple overhead and recoverabilty. > > My first goal is to reduce tuple overhead, getting rid of xmin/xman and > cmin/cmax. To provide this functionality, I'm planning to keep only a > flag indicating if the transaction is in curse or not. If, during a > transaction, a certain tuple is affected, this flag will store the > current transaction id. Thus, if this tuple is commited, an invalid OID > (say, 0), will be written to this flag. > > The only problem a saw using this approach is if some pages got flushed > during the transaction, because these pages will have to be reload from > disk. > > To address the problem of non-functional update, I pretend to store a > command identifier with the tuple, and, during update, see if the cid of > a tuple is equal of the current cid of this transaction (like we do > today). > > To keep track of current transactions, there will have a list of tuples > affected by this transaction, and the operation executed. This way, > during commit, we only confirm these operations in relations (writing an > invalid OID in current xid of each tuple affected). To rollback, we > delete the new tuples (and mark this operation as a commit) and mark the > old tuples affected as "live" (and leave these commited). > > I'm thinking of leave a transaction id for each new backend, and > postmaster will keep track of used transaction ids. This way, there is > no need to keep a list of transactions in shared memory. > > For recovery (my second goal), I pretend to, at startup of postmaster, > to rollback all marked in-curse transactions. After that, I'm thinking > about a redo log, but I'm still searching a way to keep it with the > minimum size possible. Interesting. I know we have talked in the past about the various system columns and their removal. If you check the hackers archive under cmin, etc, I think you will find some discussion. Now, as far as their removal, is it worth removing 8 bytes of tuple overhead for the gain of having to do a redo log, etc. I am not sure. I know many commercial databases have it, but I am not sure how benificial it would be. What I would really like is the ability to re-use superceeded tuples without vacuum. It seems that should be possible, but it has not been done by anyone yet. That would be a HUGE win, I think. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 http://www.op.net/~candle | (610) 353-9879(w) + If your life is a hard drive, | (610) 853-3000(h) + Christ can be your backup. |
В списке pgsql-hackers по дате отправления: