From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Vacuum improvement |
Date: | 2002-10-16 07:29:37 |
Message-ID: | Pine.LNX.4.21.0210161725160.15094-100000@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16 Oct 2002, Hannu Krosing wrote:
> On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote:
> > Hi all,
> >
> > I'm thinking that there is an improvement to vacuum which could be made
> > for 7.4. VACUUM FULLing large, heavily updated tables is a pain. There's
> > very little an application can do to minimise dead-tuples, particularly if
> > the table is randomly updated. Wouldn't it be beneficial if VACUUM could
> > have a parameter which specified how much of the table is vacuumed. That
> > is, you could specify:
> >
> > VACUUM FULL test 20 precent;
>
> What about
>
> VACUUM FULL test WORK 5 SLEEP 50;
>
> meaning to VACUUM FULL the whole table, but to work in small chunks and
> relaese all locks and let others access the tables between these ?
Great idea. I think this could work as a complement to the idea I had. To
answer Tom's question, how would we know what we've vacuumed, we could
store the range of tids we've vacuumed in pg_class. Or, we could store the
block offset of where we left off vacuuming before and using stats, run
for another X% of the heap. Is this possible?
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Kalchev | 2002-10-16 07:48:02 | Re: DROP USER weirdness in 7.2.1 |
Previous Message | Shridhar Daithankar | 2002-10-16 06:39:34 | Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry? |