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)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
