Hello,

What do you guys think of having a vacuum summary command? E.g.;

VACUUM [FULL] [ANALYZE] SUMMARY

where summary would only print the last lines of a vacuum verbose?

foo=> VACUUM SUMMARY;
INFO: free space map contains 17 pages in 12 relations
DETAIL: A total of 192 page slots are in use (including overhead).
192 page slots are required to track all free space.
Current limits are: 20000 page slots, 1000 relations, using 182 KB.
VACUUM
foo=>

Sincerely,

Joshua D. Drake


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Joshua D. Drake" <jd@commandprompt.com> writes:
> What do you guys think of having a vacuum summary command? E.g.;

> VACUUM [FULL] [ANALYZE] SUMMARY

.... that will turn SUMMARY into a fully reserved word ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>
>>What do you guys think of having a vacuum summary command? E.g.;
>
>
>>VACUUM [FULL] [ANALYZE] SUMMARY
>
>
> ... that will turn SUMMARY into a fully reserved word ...

Hmmm... good point. Other options would be:

brief
short
terse?
nutshell
review
report -- This one is interesting although sufffers from the same problem.

Sincerely,

Joshua D. Drake


>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Mon, 2005-07-11 at 12:38 -0700, Joshua D. Drake wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> >
> >>What do you guys think of having a vacuum summary command? E.g.;
> >
> >
> >>VACUUM [FULL] [ANALYZE] SUMMARY
> >
> >
> > ... that will turn SUMMARY into a fully reserved word ...
>
> Hmmm... good point. Other options would be:
>
> brief
> short
> terse?
> nutshell
> review
> report -- This one is interesting although sufffers from the same problem.
>

Good idea. I think its a good idea to make that info easily accessible.

How about putting this in the logfile, without any command changes?

Best Regards, Simon Riggs


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2005-07-11 at 12:38 -0700, Joshua D. Drake wrote:
>>> What do you guys think of having a vacuum summary command? E.g.;

> How about putting this in the logfile, without any command changes?

Actually, tying it to VACUUM might not have been such a great idea in
the first place. I think I did that because (a) the info is more likely
to be up to date just after a VACUUM (though when you consider an entire
installation rather than just one DB, this argument has big holes); and
(b) people were already accustomed to seeing a lot of blather from a
VACUUM VERBOSE command.

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?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

>
> regards, tom lane


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings