Re: Remove xmin and cmin from frozen tuples

On Thu, Sep 01, 2005 at 04:34:09PM +0100, Simon Riggs wrote:
> On Wed, 2005-08-31 at 22:25 -0400, Alvaro Herrera wrote:

> > I was thinking that when the tuple
> > needs to be obsoleted it would need to grow to accomodate the Xmax, but
> > you are not actually proposing to remove that, so it seems sensible.  In
> > fact, it is perfectly reasonable to remove Xmin and Cmin, because after
> > the tuple is frozen, the Xmin never changes again.
> 
> It's a good idea, but the Xmin is set to FrozenTransactionId, which is
> how we know it is frozen, so how can we remove Xmin? The way to do this
> is surely by using a row version id that is different for this format.

Per Takahiro's patch, you don't need to set the Xmin to
FrozenTransactionId -- what you do instead is set a bit in the infomask.


> > Now, one thing of note is that you need to "compress" the page in order
> > to actually be able to use the just-freed space.  VACUUM could do that,
> > but maybe it would be better to do it on-line -- the freezing process is
> > going to have to write the page regardless.  I wonder if with your patch
> > the page is compressed on the same VACUUM execution that freezes the
> > tuple?
> 
> Only if you do a FULL, which is currently incompatible with a FREEZE. 

Well, if we are going to mess with what FREEZE is doing, we can as well
make it compress the page.  Note that to compress the page you don't
need to touch the indexes.

I don't remember the exact reason why FULL is incompatible with FREEZE,
but AFAIR it's not fundamentally unsolvable (just very hard.)

> There's no point in compressing a block if you can't also redistribute
> rows between blocks to fill up the spaces, so another reason why it has
> to be a FULL.

That's a good point.

> > One thing that comes to mind is that this makes somewhat easier to build
> > a tool to write pre-built tables, for bulk-loading purposes.  You just
> > construct the binary file with the HEAP_FROZEN bit set, and then attach
> > the file to a dummy table.
> 
> Loading a table using COPY with frozen bits set was suggested in May, so
> yeh... it was suggested.

I'm not proposing to use COPY for that.  It has loads of problems, which
is why the patch was rejected.  Using an external program is a different
matter.

> Externally writing blocks is possible, but it bypasses a lot of other
> features.

Like what?

I don't really care for this feature, mind you -- I was merely
mentioning the idea as it crossed my mind.

-- 
Alvaro Herrera -- Valdivia, Chile         Architect, www.EnterpriseDB.com
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
         (Paul Graham)