From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | 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:11:06 |
Message-ID: | 20714.1087092666@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> On 6/12/2004 3:45 PM, Tom Lane wrote:
>> 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.
Well, it means extra I/O to freeze tuples that you otherwise probably
never would. So it's not obvious that aggressive freezing in hopes of
saving cycles later is a win.
>> It might be interesting though to have some kind of "fast vacuum" mode
>> that doesn't worry about freezing tuples, but only reclaiming dead ones.
> Wouldn't that screw the current FSM population mechanisms? Not that my
> suggestions above wouldn't do that either :-)
Yeah, that's another "wholesale" mechanism that we'd have to look at
refining.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2004-06-13 02:35:36 | Re: Big feature status |
Previous Message | Bruce Momjian | 2004-06-13 01:57:13 | Big feature status |