Skip site navigation (1) Skip section navigation (2)

Re: Vacuum summary?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum summary?
Date: 2005-07-30 03:21:19
Message-ID: 200507300321.j6U3LJV12656@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Added to TODO:

	* Add system view to show free space map contents


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

Simon Riggs wrote:
> On Tue, 2005-07-12 at 14:56 -0700, Joshua D. Drake wrote:
> > > It'd be relatively easy I think to extract the current FSM statistics
> > > in a function that could be invoked separately from VACUUM.  Not sure
> > > how we ought to return 'em though --- the VACUUM way of a bunch of INFO
> > > messages is a bit old-fashioned.  Maybe a statistics view?
> > 
> > That would work for me.
> 
> Sounds good.
> 
> I would also like the statistics view to show when all the FSM tracked
> pages are used up for a particular relation and the relation needs
> vacuuming. That way we can integrate it with autovacuum.
> 
> Best Regards, Simon Riggs
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 

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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-07-30 03:24:37
Subject: Re: PL/Perl list value return causes segfault
Previous:From: Bruce MomjianDate: 2005-07-30 03:15:05
Subject: Re: Must be owner to truncate?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group