From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, mkoi-pg(at)aon(dot)at |
Subject: | Re: Getting rid of cmin and cmax |
Date: | 2006-09-19 14:59:07 |
Message-ID: | 451005BB.5050202@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>
>> I'm thinking of removing cmin and cmax, and keeping that information in
>> backend-private memory instead.
>>
>
> I don't believe you can remove *both*. What's been discussed is
> removing one of them, by letting the field represent a lookup key for an
> in-memory structure in the infrequent case that xmin and xmax are both
> the current xact. You solve the table size problem by only having one
> entry for each unique cmin/cmax pair in use.
>
That's another possibility, but removing both cmin and cmax has also
been discussed. It's also mentioned in the TODO item:
> One possible solution is to create a phantom cid which represents a
cmin/cmax pair and is stored in local memory. *Another idea is to store
both cmin and cmax only in local memory.*
Saving 4 bytes per tuple with the phantom cid is nice, but saving 8
bytes (assuming we get rid of xvac in the future, or overlay it with
xmin for example) is even better.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2006-09-19 15:05:02 | Re: [HACKERS] Incrementally Updated Backup |
Previous Message | Sim Zacks | 2006-09-19 14:53:12 | Re: vista |