Re: Multi-Versions and Vacuum

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andrew Sullivan <andrew(at)libertyrms(dot)info>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Multi-Versions and Vacuum
Date: 2002-08-27 16:14:20
Message-ID: 200208271614.g7RGEKp28140@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Added to TODO:

* Allow free space map to be auto-sized or warn when it is too small

---------------------------------------------------------------------------

Andrew Sullivan wrote:
> On Fri, Jul 19, 2002 at 12:35:23PM -0400, Tom Lane wrote:
>
> > After VACUUM does its thing (and yes, it removes everything it legally
> > can) it reports the amount of free space it found on each page to the
> > FSM, and the FSM remembers as much of that info as it has room for ---
> > preferring pages with more free space, if it has to be selective.
>
> I think this is where the confusion lies. The ever-growing tables
> that people are experiencing is somehow related to the new
> non-blocking vacuum and the value of the free space map settings.
> Previous posts on the matter have left some (well, me, at least) with
> the idea that the non-blocking vacuum doesn't get everything, just in
> case the free space map values are too small.
>
> But if I understand now what you're saying, it's this: the vacuum
> _does_ get everything, but if the free space map settings are too
> small, the free space map doesn't know about that free space;
> therefore, the space never gets re-used for future data, because as
> far as the postmaster is concerened, the space isn't available. So
> the tables keep growing because they have to append their data at the
> end of the file (because the free space map hasn't reported any free
> space). Run vacuum a few times like this, and there is a substantial
> amount of unused space in the tables, where the free space map
> doesn't have an entry for it. Is that right?
>
> If so, it should be possible to calculate what one needs for the
> max_fsm_pages setting by calculating how much data is replaced or
> deleted in any given period, vacuum-to-vacuum, I guess. What one
> would need to do is calculate how much space a row is taking up on
> disk, and then set the max_fsm_pages to comprise (almost?) enough
> space to keep a map big enough to include all the rows likely to be
> recovered by vacuum. Or am I completely mad? (I know, I know, "Yes"
> is a possible answer there.)
>
> A
>
> --
> ----
> Andrew Sullivan 87 Mowat Avenue
> Liberty RMS Toronto, Ontario Canada
> <andrew(at)libertyrms(dot)info> M6K 3E3
> +1 416 646 3304 x110
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2002-08-27 16:27:13 Re: Free space mapping (was Re: Multi-Versions and Vacuum)
Previous Message Ben-Nes Michael 2002-08-27 16:05:38 Re: how to count string occurrence in column