From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "mlw" <markw(at)mohawksoft(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgresql backend to perform vacuum automatically |
Date: | 2002-03-06 08:35:16 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961D61@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Turbo Fredriksson | 2002-03-06 09:06:29 | Re: Postgresql backend to perform vacuum automatically |
Previous Message | Turbo Fredriksson | 2002-03-06 08:19:45 | Drop in performance for each INSERT/DELETE combo |