From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, mkoi-pg(at)aon(dot)at |
Subject: | Re: Remove xmin and cmin from frozen tuples |
Date: | 2005-09-07 17:38:07 |
Message-ID: | 28450.1126114687@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-09-07 17:44:02 | Re: Remove xmin and cmin from frozen tuples |
Previous Message | Alvaro Herrera | 2005-09-07 17:30:07 | Re: Remove xmin and cmin from frozen tuples |