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
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 |