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
>
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 |