Thread: VACUUM VERBOSE 8.1dev

VACUUM VERBOSE 8.1dev

From
"Joshua D. Drake"
Date:
Hello,

It seems the new VACUUM VERBOSE output is not quite as helpful as 8.0.
In 8.0 I get a nice output at the end like this:

INFO:  free space map: 1377 relations, 22478 pages stored; 44112 total 
pages needed
DETAIL:  Allocated FSM size: 100000 relations + 2000000 pages = 17702 kB 
shared memory.

Which tells me exactly what I need to do with max_fsm_pages/relations.

The new output appears:

booktown=# VACUUM FULL VERBOSE books ;
INFO:  vacuuming "public.books"
INFO:  "books": found 32804 removable, 14 nonremovable row versions in 
242 pages
DETAIL:  0 dead row versions cannot be removed yet.
Nonremovable row versions range from 48 to 72 bytes long.
There were 0 unused item pointers.
Total free space (including removable row versions) is 1845484 bytes.
241 pages are or will become empty, including 241 at the end of the table.
1 pages containing 6768 free bytes are potential move destinations.

I am sure the above tells me the same thing but not as easily.

Comments?

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/



Re: VACUUM VERBOSE 8.1dev

From
Tom Lane
Date:
"Joshua D. Drake" <jd@commandprompt.com> writes:
> It seems the new VACUUM VERBOSE output is not quite as helpful as 8.0.
> In 8.0 I get a nice output at the end like this:

> INFO:  free space map: 1377 relations, 22478 pages stored; 44112 total 
> pages needed
> DETAIL:  Allocated FSM size: 100000 relations + 2000000 pages = 17702 kB 
> shared memory.

AFAIR, in both 8.0 and 8.1 that info appears only at the end of a
database-wide vacuum.  Your example is a single-table vacuum, which
certainly doesn't show that info in 8.0 ...
        regards, tom lane


Re: VACUUM VERBOSE 8.1dev

From
"Joshua D. Drake"
Date:
>>INFO:  free space map: 1377 relations, 22478 pages stored; 44112 total 
>>pages needed
>>DETAIL:  Allocated FSM size: 100000 relations + 2000000 pages = 17702 kB 
>>shared memory.
>>    
>>
>
>AFAIR, in both 8.0 and 8.1 that info appears only at the end of a
>database-wide vacuum.  Your example is a single-table vacuum, which
>certainly doesn't show that info in 8.0 ...
>  
>
You are absolutely (as usual) correct. Thank you. I was just
writing a retraction as I read your post.

Sincerely,

Josuha D. Drake


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



Re: VACUUM VERBOSE 8.1dev

From
Dave Cramer
Date:
I'm not even sure that the new output does tell me the same thing.

I certainly prefer the previous output. I think this will be very  
confusing to users
who aren't familiar with the internals of postgres.

Dave
On 13-Sep-05, at 11:44 PM, Joshua D. Drake wrote:

> Hello,
>
> It seems the new VACUUM VERBOSE output is not quite as helpful as 8.0.
> In 8.0 I get a nice output at the end like this:
>
> INFO:  free space map: 1377 relations, 22478 pages stored; 44112  
> total pages needed
> DETAIL:  Allocated FSM size: 100000 relations + 2000000 pages =  
> 17702 kB shared memory.
>
> Which tells me exactly what I need to do with max_fsm_pages/relations.
>
> The new output appears:
>
> booktown=# VACUUM FULL VERBOSE books ;
> INFO:  vacuuming "public.books"
> INFO:  "books": found 32804 removable, 14 nonremovable row versions  
> in 242 pages
> DETAIL:  0 dead row versions cannot be removed yet.
> Nonremovable row versions range from 48 to 72 bytes long.
> There were 0 unused item pointers.
> Total free space (including removable row versions) is 1845484 bytes.
> 241 pages are or will become empty, including 241 at the end of the  
> table.
> 1 pages containing 6768 free bytes are potential move destinations.
>
> I am sure the above tells me the same thing but not as easily.
>
> Comments?
>
> 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 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
>
>