Re: Postgresql backend to perform vacuum automatically - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: Postgresql backend to perform vacuum automatically
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961D66@m0114.s-mxs.net
Whole thread Raw
In response to Postgresql backend to perform vacuum automatically  ("Nicolas Bazin" <nbazin@ingenico.com.au>)
Responses Re: Postgresql backend to perform vacuum automatically  (<mkscott@sacadia.com>)
Re: Postgresql backend to perform vacuum automatically  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > I still think, that for best results the vacuums should happen continuously
> > for single pages based on a hook in wal or the buffer manager.
>
> Not possible unless you are willing to have SELECTs grab much stronger
> locks than they do now (viz, the same kind of lock that VACUUM does).

I am talking about slots, that are marked deleted before oldest tx in progress.
It should be possible to overwrite those only with the "pin" on the page.
A pageread for a select does wait (spinlock) while a new txinfo is written,
this is necessary since the txinfo is more than one byte, no ?
It should be more or less the same situation like using a slot from the
freelist, no ?
Update and delete would need to check the "old page" for %free and add it to
the freelist, like vacuum does.

This would avoid the (imho large) overhead vacuum imposes of reading static
pages that have not been modified in ages.

Andreas


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Bad Build
Next
From: Karel Zak
Date:
Subject: Re: date formatting and tab-complete patch