Re: [GENERAL] Upgrade to dual processor machine? - Mailing list pgsql-performance

From Cedric Dufour (Cogito Ergo Soft)
Subject Re: [GENERAL] Upgrade to dual processor machine?
Date
Msg-id NDBBIFNBODNADCAOFDOAMEEPCEAA.cedric.dufour@cogito-ergo-soft.com
Whole thread Raw
In response to Re: [GENERAL] Upgrade to dual processor machine?  (Andrew Sullivan <andrew@libertyrms.info>)
Responses Re: [GENERAL] Upgrade to dual processor machine?  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-performance
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Andrew
> Sullivan
> Sent: Friday, November 15, 2002 13:59
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] [GENERAL] Upgrade to dual processor machine?
>
>
> On Fri, Nov 15, 2002 at 09:47:23AM +0100, Cedric Dufour (Cogito
> Ergo Soft) wrote:
> > Is there any setting in the conf file that is related to this VACUUM and
> > dead tuples issue ? Could the "free-space map" settings be
> related (I never
> > understood what were these settings) ?
>
> Yes.  That's what those settings are.
>

The 'Runtime configuration / General operation' part of the doc is quite
short on the subject.

Is there any other places to look for more details on this FSM ? What policy
should drive changes to the FSM settings ?

I guess allowing larger FSM values might improve UPDATE performance (require
VACUUM less often) but consume RAM that may be more useful elsewhere. Am I
right ?

Has any one made experience on that matter and what conclusion were drawn ?
In other words, shall we try to alter this FSM settings for better
perfomance or is it better to stick to a regular (shortly timed) VACUUM
scenario ?

    Cedric



pgsql-performance by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: [GENERAL] Upgrade to dual processor machine?
Next
From: Richard Huxton
Date:
Subject: Re: for/loop performance in plpgsql ?