Re: Remove xmin and cmin from frozen tuples

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "Jim C. Nasby" <jnasby@pervasive.com>, Bruce Momjian <pgman@candle.pha.pa.us>, ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp>, pgsql-hackers@postgresql.org, mkoi-pg@aon.at
Date: 2005-09-07T17:38:07Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I'm curious to know how can you store the cmin/cmax pair completely out
> of the tuple.  It's easy to see how to store a single identifier in each
> tuple that would be an index to a structure in local memory.  However,
> to eliminate both you'd have to keep a list of all tuples you have
> created or obsoleted, with the cmin and cmax of each.  This seems like
> an awful amount of memory.

Yeah.  I think a reasonable compromise scheme is to try to get down to
three fields per tuple:

	xmin	same as now
	xmax	same as now
	cid/xvac

xvac can share storage with the command ID info as long as VACUUM FULL
never tries to move a tuple whose originating or deleting transaction
is still running ... which is pretty much the same restriction we had
before.

For the command IDs, I am imagining:

if created in current transaction: use cid to store cmin

if deleted in current transaction: use cid to store cmax

if both created and deleted in current transaction: cid is an index
into an in-memory data structure that contains cmin and cmax.

"current transaction" would have to have the loose definition that
includes any subxact of the current top xact, but still, I think that
the case where you need both fields is relatively uncommon.

The in-memory data structure would only need to contain an entry for
each distinct combination of cmin and cmax used in the current xact,
so I think we could assume that it would never get unreasonably large.
The entries would be created "on demand" much like we do for
multixact ids (I guess you'd want a hash table to map requested
cmin/cmax to an existing entry ID quickly).

			regards, tom lane