| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Marshall <smarshall(at)wsicorp(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: Bug #769: Slow vacuuming due to error in optimization |
| Date: | 2002-09-16 21:04:44 |
| Message-ID: | 2053.1032210284@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Stephen Marshall <smarshall(at)wsicorp(dot)com> writes:
> Tom Lane wrote:
>> How large is "large", and what FSM parameters are you using? Do you
>> know how many pages were getting passed into MultiRecordFreeSpace?
> vacuum_mem is 16384
> max_fsm_relations is 100
> max_fsm_pages is 300000
> pg_largeobject data size = 4211617.693 K
> pg_largeobject file size = 7932208.000 K
> number of large objects = 870
> number of lo pages = 2106287
> number of messages = 469458
> Upon vacuuming, I found 300000 pages were passed to MultiRecordFreeSpace,
> with the minPage specified as 0 and the maxPage as -2. The pages passed
> exactly equaled the max_fsm_pages parameter.
Yeah; if you look at vacuumlazy.c you'll see it doesn't bother keeping
track of more than max_fsm_pages, since it knows the FSM will not
remember more than that either.
> This vacuum took over 30 minutes, with more than 25 minutes spent in
> MultiRecordFreeSpace.
Yow. Definitely need to fix that code ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2002-09-16 23:08:04 | Re: Postgres storing time in strange manner |
| Previous Message | Tom Lane | 2002-09-16 18:29:31 | Re: Bug #769: Slow vacuuming due to error in optimization |