Re: Why frequently updated tables are an issue

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-12 22:04:37
Message-ID: 40CB7DF5.9050601@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

>
> 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.
> This could look at only recently touched pages, with perhaps the
> cooperation of the bgwriter to keep track of candidate pages. (You'd
> still have to do full-database scans for freezable tuples occasionally ...
> but not very often.)

Wouldn't that screw the current FSM population mechanisms? Not that my
suggestions above wouldn't do that either :-)

>
> The main thing I don't see how to handle efficiently is getting rid of
> the index entries for dead rows. The present indexam API is designed
> for getting rid of index entries wholesale, but you'd need something
> that works better for retail removal to approach vacuuming this way.

Which is a problem so fundamentally embedded in the index implementation
itself that is sounds more like a wholesale replacement of the index am
than some nifty changes.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Hallgren 2004-06-12 23:23:49 Re: I just got it: PostgreSQL Application Server -- a new project.
Previous Message Bruce Momjian 2004-06-12 22:03:23 Re: Releasing 7.4.3 ...