Re: VACUUM optimization ideas.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: hstenger(at)ieee(dot)org
Cc: Alfred Perlstein <bright(at)wintelcom(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: VACUUM optimization ideas.
Date: 2000-10-12 18:56:10
Message-ID: 200010121856.OAA10379@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Alfred Perlstein wrote:
> > #1
> >
> > Reducing the time vacuum must hold an exlusive lock on a table:
> >
> > The idea is that since rows are marked deleted it's ok for the
> > vacuum to fill them with data from the tail of the table as
> > long as no transaction is in progress that has started before
> > the row was deleted.
> >
> > This may allow the vacuum process to copyback all the data without
> > a lock, when all the copying is done it then aquires an exlusive lock
> > and does this:
> >
> > Aquire an exclusive lock.
> > Walk all the deleted data marking it as current.
> > Truncate the table.
> > Release the lock.
> >
> > Since the data is still marked invalid (right?) even if valid data
> > is copied into the space it should be ignored as long as there's no
> > transaction occurring that started before the data was invalidated.
>
> Yes, but nothing prevents newer transactions from modifying the _origin_ side of
> the copied data _after_ it was copied, but before the Lock-Walk-Truncate-Unlock
> cycle takes place, and so it seems unsafe. Maybe locking each record before
> copying it up ...

Seems a read-lock would be necessary during the moving, but still a win.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-10-12 18:57:55 Re: VACUUM optimization ideas.
Previous Message Tom Lane 2000-10-12 18:55:50 Re: AW: ALTER TABLE DROP COLUMN