Sven Willenberger presumably uttered the following on 07/07/06 13:52: > On Fri, 2006-07-07 at 10:41 -0700, Joshua D. Drake wrote: >>>> Sincerely, >>>> >>>> Joshua D. Drake >>> Doing a quick check reveals that the relation in question currently >>> consumes 186GB of space (which I highly suspect is largely bloat). >> Good lord.. .186 gig for a 300 million row table? Unless those are seriously >> large rows, you have a TON of bloat. >> >> Joshua D. Drake >> > > Yes, that number came from the dbsize functions (in contrib) so I don't > know if that includes the associated indexes as well. The rows are > fairly large, yes, but not enough (IMO) to account for that size. It > will be interesting to see the final size after the vacuum full (which > is the method I have settled on to reclaim space this go round). > > Sven > > > ---------------------------(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 Unfortunately it would appear that I cannot vacuum full either as I get an out of memory error: # - Memory - shared_buffers = 5000 # min 16, at least max_connections*2, 8KB each work_mem = 131072 # min 64, size in KB maintenance_work_mem = 524288 # min 1024, size in KB max_stack_depth = 4096 # min 100, size in KB /boot/loader.conf kern.maxdsiz="1610612736" kern.dfldsiz="891289600" I have disabled other connections to the db except for slony (which will not access the table in question). I begin a Vacuum full <tablename> and start watching memory use constantly increase (top). It pushes to: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 61048 pgsql -4 0 1640M 1472M getblk 1 6:58 16.75% 16.75% postgres and then it bails: ERROR: out of memory DETAIL: Failed on request of size 78. Server version is 8.03 Is this a known issue? Sven
