RE: Plans for solving the VACUUM problem

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Jan Wieck'" <JanWieck(at)Yahoo(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'The Hermit Hacker'" <scrappy(at)hub(dot)org>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Plans for solving the VACUUM problem
Date: 2001-05-21 17:37:58
Message-ID: 3705826352029646A3E91C53F7189E32016635@sectorbase2.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> From: Mikheev, Vadim
> Sent: Monday, May 21, 2001 10:23 AM
> To: 'Jan Wieck'; Tom Lane
> Cc: The Hermit Hacker; 'Bruce Momjian';
> pgsql-hackers(at)postgresql(dot)orgrg(dot)us(dot)greatbridge(dot)com

Strange address, Jan?

> Subject: RE: [HACKERS] Plans for solving the VACUUM problem
>
>
> > I think the in-shared-mem FSM could have some max-per-table
> > limit and the background VACUUM just skips the entire table
> > as long as nobody reused any space. Also it might only
> > compact pages that lead to 25 or more percent of freespace in
> > the first place. That makes it more likely that if someone
> > looks for a place to store a tuple that it'll fit into that
> > block (remember that the toaster tries to keep main tuples
> > below BLKSZ/4).
>
> This should be configurable parameter like PCFREE (or something
> like that) in Oracle: consider page for insertion only if it's
> PCFREE % empty.
>
> Vadim
>

Browse pgsql-hackers by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2001-05-21 17:38:46 Re: Using 7.1rc1 under RH 6.2
Previous Message Tom Lane 2001-05-21 17:22:53 Re: Plans for solving the VACUUM problem