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
It really should be telling you how many pages it wanted, and are in use. If not, something odd is going on.
