Skip site navigation (1) Skip section navigation (2)

Re: Resumable vacuum proposal and design overview

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Galy Lee" <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Resumable vacuum proposal and design overview
Date: 2007-02-28 13:19:50
Message-ID: 873b4qpgg9.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

> How much memory would it save during VACUUM on a 1 billion row table
> with 200 million dead rows? Would that reduce the number of cycles a
> normal non-interrupted VACUUM would perform?

It would depend on how many dead tuples you have per-page. If you have a very
large table with only one dead tuple per page then it might even be larger.
But in the usual case it would be smaller.

Also note that it would have to be non-lossy.

My only objection to this idea, and it's not really an objection at all, is
that I think we want to head in the direction of making indexes cheaper to
scan and doing the index scan phase more often. That reduces the need for
multiple concurrent vacuums and makes the problem of busy tables getting
starved less of a concern.

That doesn't mean there's any downside to making the dead tuple list take less
memory but I think the upside is limited. As we optimize our index
representations with GII and bitmapped indexes scanning them gets easier and
easier anyways. And you don't really want to wait too long before you get the
benefit of the recovered space in the table.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Zoltan BoszormenyiDate: 2007-02-28 13:25:14
Subject: Re: psql problem querying relations
Previous:From: Simon RiggsDate: 2007-02-28 13:10:28
Subject: Major Feature Interactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group