"Ed L." <[EMAIL PROTECTED]> writes:
> If it were indeed the case that we'd leaked a lot of diskspace, then after
> bumping max_fsm_pages up to a much higher number (4M), will these pages
> gradually be "remembered" as they are accessed by autovac and or queried,
> etc? Or is a dump/reload or 'v
Jeff Boes <[EMAIL PROTECTED]> writes:
> At some point, someone was going to write a "white paper" detailing how one
> might go about setting these parameters.
In 7.4, it's relatively easy to check on whether your settings are
reasonable: just do a VACUUM VERBOSE (database-wide) and check the
FSM r
On Friday May 7 2004 12:20, Ed L. wrote:
>
> 1) I'm inclined to set this to handle as large a DB footprint as will be
> in the coming year or two, so maybe 3X what it is now. What is the
> impact/cost of setting max_fsm_pages at, say, 3M for an 8GB footprint?
> (3 x 8GB/8K)
Ok, so I see 40B per
At some point in time, [EMAIL PROTECTED] (Tom Lane) wrote:
>
>> max_fsm_relations = 1000 and max_fsm_pages = 1.
>
>Also you doubtless need max_fsm_pages a lot higher than that. A
>conservative setting would make it as big as your whole database,
>eg for a 10Gb disk footprint use 10Gb/8K (some
"Ed L." <[EMAIL PROTECTED]> writes:
> 2) Would this low setting of 1 explain the behavior we saw of seqscans
> of a perfectly analyzed table with 1000 rows requiring ridiculous amounts
> of time even after we cutoff the I/O load?
Possibly. The undersized setting would cause leakage of disk
"Ed L." <[EMAIL PROTECTED]> writes:
> Sorry, I see that's *6B* per, so setting it to 3M ==> 18MB, which is trivial
> for the benefit. Any other concerns in setting this too high?
Not that I know of.
regards, tom lane
---(end of broadcast)
On Friday May 7 2004 12:23, Ed L. wrote:
> On Friday May 7 2004 12:20, Ed L. wrote:
> > 1) I'm inclined to set this to handle as large a DB footprint as will
> > be in the coming year or two, so maybe 3X what it is now. What is the
> > impact/cost of setting max_fsm_pages at, say, 3M for an 8GB f
On Friday May 7 2004 11:25, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > No, our autovac logs the number of changes (upd+del for vac,
> > upd+ins+del for analyze) on each round of checks, and we can see it was
> > routinely performing when expected. The number of updates/deletes just
"Ed L." <[EMAIL PROTECTED]> writes:
> No, our autovac logs the number of changes (upd+del for vac, upd+ins+del for
> analyze) on each round of checks, and we can see it was routinely
> performing when expected. The number of updates/deletes just far exceeded
> the thresholds. Vac threshold was
On Friday May 7 2004 9:09, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > I guess the activity just totally outran the ability of autovac to keep
> > up.
>
> Could you have been bit by autovac's bug with misreading '3e6' as '3'?
> If you don't have a recent version it's likely to fail to
"Ed L." <[EMAIL PROTECTED]> writes:
> I guess the activity just totally outran the ability of autovac to keep up.
Could you have been bit by autovac's bug with misreading '3e6' as '3'?
If you don't have a recent version it's likely to fail to vacuum large
tables often enough.
11 matches
Mail list logo
