From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
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 15:57:23 |
Message-ID: | 6661.1158681443@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> 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.
xvac is not going away, so that argument is unconvincing, and I don't
believe you can avoid blowing out local memory if you have to remember
each tuple's cmin/cmax separately. (Notice that Manfred gave up on his
patch for lack of a spill-to-disk mechanism.)
I'm also concerned about loss of debug traceability if these fields
disappear entirely from disk --- it's been handy more than once to be
able to tell where in a complex transaction something happened.
Lastly, at least on machines with 8-byte MAXALIGN, removing four more
bytes from heap headers would save nothing. So I'm not excited about
going through enormous pushups to get rid of both fields, when a far
simpler and better-performing mechanism suffices to remove one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ben | 2006-09-19 16:03:18 | Re: vista |
Previous Message | Paul B. Anderson | 2006-09-19 15:41:39 | Re: Vacuum error on database postgres |