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 46C15C39FEB2C44BA555E356FBCD6FA4961D61@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > > > If they do not affect performance, then why have them off?
> > >
> > > I think Jan said 2-3%.  If we can get autovacuum from it, it would be a
> > > win to keep it on all the time, perhaps.
> >
> > Assuming that the statistics get updated:
> >
> > How often should the sats table be queried?
> > What sort of configurability would be needed?
>
> You could wake up every few minutes and see how the values have changed.
> I don't remember if there is a way to clear that stats so you can see
> just the changes in the past five minutes.  Vacuum the table that had
> activity.

I cannot envision querying the stats every 4 seconds, especially if the stats
thread already has most of the info in hand.

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. Do I remember
correctly, that the active page (the one receiving the next row) already has
a strategy for slot reuse ? Maybe this strategy should be the followed more
aggressively ?

Seems the worst case is a few row table that permanently get updated,
it should be possible to harness this situation with above method.

Andreas


pgsql-hackers by date:

Previous
From: Turbo Fredriksson
Date:
Subject: Drop in performance for each INSERT/DELETE combo
Next
From: Turbo Fredriksson
Date:
Subject: Re: Postgresql backend to perform vacuum automatically