Re: Remove xmin and cmin from frozen tuples

On Fri, Sep 02, 2005 at 01:35:42PM -0700, Josh Berkus wrote:

> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Considering the cost/benefits, rather than doing some optimization for
> > > long-lived tuples, I would like to see us merge the existing
> > > xmin/xmax/cmin/cmax values back into three storage fields like we had
> > > in 7.4 and had to expand to a full four in 8.0 to support
> > > subtransactions.
> 
> Hmmm.   I personally don't see a whole lot of value in trimming 4 bytes per 
> row off an archive table, particularly if the table would need to go 
> through some kind of I/O intensive operation to do it.

I think you are missing something.  These 4 bytes are not trimmed by an
I/O-intensive operation, they are not written in the first place.

Now, I agree for a very wide table those 4 bytes per tuple may not be a
lot.  But the optimization could be significant for not-wide (uh, sorry,
I don't remember the word) tables. 

> Where I do see value is in enabling index-only access for "frozen" tables.  
> That would be a *huge* gain, especially with bitmaps.   I think we've 
> discussed this before, though.

That's a completely different discussion.  Btree-organized heaps may
help you there.

-- 
Alvaro Herrera -- Valdivia, Chile         Architect, www.EnterpriseDB.com
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)