| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
| Cc: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, The Hermit Hacker <scrappy(at)hub(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Plans for solving the VACUUM problem |
| Date: | 2001-05-22 17:32:40 |
| Message-ID: | 200105221732.f4MHWef08905@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
[ Charset ISO-8859-1 unsupported, converting... ]
> > > My point is that we'll need in dynamic cleanup anyway and UNDO is
> > > what should be implemented for dynamic cleanup of aborted changes.
> >
> > I do not yet understand why you want to handle aborts different than
> > outdated tuples.
>
> Maybe because of aborted tuples have shorter Time-To-Live.
> And probability to find pages for them in buffer pool is higher.
This brings up an idea I had about auto-vacuum. I wonder if autovacuum
could do most of its work by looking at the buffer cache pages and
commit xids. Seems it would be quite easy record freespace in pages
already in the buffer and collect that information for other backends to
use. It could also move tuples between cache pages with little
overhead.
There wouldn't be an I/O overhead, and frequently used tables are
already in the cache.
--
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-05-22 17:47:15 | Re: Plans for solving the VACUUM problem |
| Previous Message | The Hermit Hacker | 2001-05-22 17:31:49 | Not released yet, but could someone take a quick peak ... |