RE: Plans for solving the VACUUM problem

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, 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: RE: Plans for solving the VACUUM problem
Date: 2001-05-21 16:31:15
Message-ID: 3705826352029646A3E91C53F7189E32016630@sectorbase2.sectorbase.com
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.

Yes, some daemon could read logs and gather cleanup info.
We could activate it when switching to new log file segment
and synchronization with checkpointer is not big deal. That
daemon would also archive log files for WAL-based BAR,
if archiving is ON.

But this will be useful only with on-disk FSM.

Vadim

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2001-05-21 16:40:54 Re: [GENERAL] Queries across multiple databases  (was: SELECT from a table in another database).
Previous Message Andrew Rawnsley 2001-05-21 16:26:11 Re: Queries across multiple databases (was: SELECT from a table in another database).