| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'Vadim Mikheev'" <vmikheev(at)sectorbase(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | AW: Plans for solving the VACUUM problem |
| Date: | 2001-05-21 15:49:28 |
| Message-ID: | 11C1E6749A55D411A9670001FA6879633682DF@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Really?! Once again: WAL records give you *physical* address of tuples
> (both heap and index ones!) to be removed and size of log to read
> records from is not comparable with size of data files.
So how about a background "vacuum like" process, that reads the WAL
and does the cleanup ? Seems that would be great, since it then does not
need to scan, and does not make forground cleanup necessary.
Problem is when cleanup can not keep up with cleaning WAL files, that already
want to be removed. I would envision a config, that sais how many Mb of WAL
are allowed to queue up before clients are blocked.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zeugswetter Andreas SB | 2001-05-21 16:00:58 | AW: Plans for solving the VACUUM problem |
| Previous Message | Tom Lane | 2001-05-21 15:47:54 | Re: AW: Fix for tablename in targetlist |