vacuumdb -a -v -z -U postgres -W &> vacuum.log
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
Password:
cruxnu:nsbuildout crucial$
do you think its possible that it just doesn't have anything to complain about ?
or the password is affecting it ?
In any case I'm not sure I want to run this even at night on production.
what is the downside to estimating max_fsm_pages too high ?
3000000 should be safe
its certainly not 150k
I have one very large table (10m) that is being analyzed before I warehouse it.
that could've been the monster that ate the free map.
I think today I've learned that even unused tables affect postgres performance.
and do you agree that I should turn CLUSTER ON ?
I have no problem to stop all tasks to this table at night and just reload it
On Fri, Feb 4, 2011 at 6:47 PM, Shaun Thomas
<sthomas@peak6.com> wrote:
On 02/04/2011 11:44 AM, felix wrote:
the very end:
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: analyzing "public.seo_partnerlinkcategory"
INFO: "seo_partnerlinkcategory": scanned 0 of 0 pages, containing 0 live
rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
That looks to me like it didn't finish. Did you fork it off with '&' or run it and wait until it gave control back to you?
It really should be telling you how many pages it wanted, and are in use. If not, something odd is going on.