Re: Getting rid of cmin and cmax

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

In response to

Responses

Browse pgsql-hackers by date

  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