Re: Remove xmin and cmin from frozen tuples
От | Tom Lane |
---|---|
Тема | Re: Remove xmin and cmin from frozen tuples |
Дата | |
Msg-id | 28450.1126114687@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Remove xmin and cmin from frozen tuples (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Remove xmin and cmin from frozen tuples
|
Список | 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 nowxmax same as nowcid/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
В списке pgsql-hackers по дате отправления: