From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | rmiranda(at)rudah(dot)com(dot)br (Robson Miranda) |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Transaction system (proposal for 6.5) |
Date: | 1998-09-21 01:34:33 |
Message-ID: | 199809210134.VAA15365@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)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. |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-09-21 01:43:07 | Re: [HACKERS] query crashes backend - cvs |
Previous Message | Bruce Momjian | 1998-09-21 01:29:42 | Re: [HACKERS] query crashes backend - cvs |