| From: | Doug McNaught <doug(at)mcnaught(dot)org> |
|---|---|
| To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Huge pg_toast table |
| Date: | 2003-07-24 21:03:43 |
| Message-ID: | m3znj3skls.fsf@varsoon.wireboard.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Ed L." <pgsql(at)bluepolka(dot)net> writes:
> On Thursday July 24 2003 2:53, Ed L. wrote:
> > I have a frequently updated table called 'audit' with 10,000 rows of
> > about 90kb per row (90kb * 10k = 900mb). There is a 35gb system table
> > called pg_toast_NNNNN where NNNNN is the oid of the 'audit' table.
> >
> > My question: should I expect a 'vacuum full' to shrink the size of this
> > pg_toast table? I ask instead of just doing it because doing so would
> > require scheduling customer downtime since 'vacuum full' blocks access.
>
> BTW, we currently run 'analyze' every 2 hours and vacuum once daily on this
> 7.3.2 cluster....
You might want to check your FSM (free space map) settings--it sounds
like you're losing track of some pages that (non-blocking) vacuum
could salvage, saving you from having to VACUUM FULL. There's been a
fair amount of discussion about FSM tuning if you check the
archives...
-Doug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vivek Khera | 2003-07-24 21:06:12 | Re: dump_all/restore times? |
| Previous Message | Ed L. | 2003-07-24 20:59:35 | Re: Huge pg_toast table |