Re: Why frequently updated tables are an issue

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shridhar Daithankar <shridhar(at)frodo(dot)hserus(dot)net>, pgsql(at)mohawksoft(dot)com, Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why frequently updated tables are an issue
Date: 2004-06-13 02:37:25
Message-ID: 200406130237.i5D2bPH13318@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck wrote:
> On 6/12/2004 3:45 PM, Tom Lane wrote:
>
> > Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> >> But a per relation bitmap that tells if a block is a) free of dead
> >> tuples and b) all remaining tuples in it are frozen could be used to let
> >> vacuum skip them (there can't be anything to do). The bit would get
> >> reset whenever the block is marked dirty. This would cause vacuum to
> >> look at mainly recently touched blocks, likely to be found in the buffer
> >> cache anyway and thus dramatically reduce the amount of IO and thereby
> >> make high frequent vacuuming less expensive.
> >
> > I don't think it would help very much to define a bit like that --- I
> > can't believe that very many pages would contain only frozen tuples,
> > unless you were to adopt an aggressive policy of using VACUUM FREEZE
> > a lot.
>
> I thought this implies an aggressive policy of freezing everything by
> default. But I guess there is something I am not aware of that makes
> aggressive freezing a bad thing.

Why are frozen tuples significant? I assume any page that has no dead
tuples could be skipped by vacuum.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-06-13 02:39:21 Re: Big feature status
Previous Message Matthew T. O'Connor 2004-06-13 02:35:36 Re: Big feature status