From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Remove xmin and cmin from frozen tuples |
Date: | 2005-09-01 18:55:45 |
Message-ID: | 5271.1125600945@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> 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:
>>> 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.
Anyone looked at the code lately???
PageRepairFragmentation is part of any kind of vacuum. As long as you
don't reassign tuple IDs (which it doesn't) there's no impact on indexes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-09-01 18:59:37 | Re: upgrade path / versioning roles |
Previous Message | Tom Lane | 2005-09-01 18:53:12 | Re: Version number in psql banner |