Index: runtime.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.214
diff -r1.214 runtime.sgml
2c2
< $Header: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v 1.214 2003/10/17 22:38:20 tgl Exp $
---
> $Header: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v 1.213 2003/10/10 02:08:42 momjian Exp $
27c27
< this user because compromised systems could then modify their own
---
> this user because compromised systems could then modify their own
469c469
< One way to set these parameters is to edit the file
---
> One way to set these options is to edit the file
479c479
< One parameter is specified per line. The equal sign between name and
---
> One option is specified per line. The equal sign between name and
520c520
< parameters that are fixed when the server is started, such as the port
---
> options that are fixed when the server is started, such as the port
524a525,534
> Some options can be changed in individual SQL
> sessions with the SET command, for example:
>
> SET ENABLE_SEQSCAN TO OFF;
>
> See the SQL command language reference for
> details on the syntax.
>
>
>
530c540
< settings. Per-database settings override anything received
---
> settings. Such per-database settings override anything received
533c543
< settings; both are overridden by per-session options.
---
> settings.
537,545c547,552
< Some parameters can be changed in individual SQL
< sessions with the
< command, for example:
<
< SET ENABLE_SEQSCAN TO OFF;
<
< If SET is allowed, it overrides all other sources of
< values for the parameter. Superusers are allowed to SET
< more values than ordinary users.
---
> The virtual table pg_settings allows
> displaying and updating session run-time parameters. It contains one
> row for each configuration parameter; the columns are shown in
> . This table allows the
> configuration data to be joined with other tables and have a
> selection criteria applied.
546a554,655
>
>
> An UPDATE performed on pg_settings
> is equivalent to executing the SET command on that named
> parameter. The change only affects the value used by the current session. If
> an UPDATE is issued within a transaction that is later
> aborted, the effects of the UPDATE command disappear when
> the transaction is rolled back. Once the surrounding transaction is
> committed, the effects will persist until the end of the session, unless
> overridden by another UPDATE or SET.
>
>
>
> <literal>pg_settings</> Columns
>
>
>
>
> Name
> Data Type
> Description
>
>
>
>
>
> name
> text
> run-time configuration parameter name
>
>
>
> setting
> text
> current value of the parameter
>
>
>
> context
> text
> context required to set the parameter's value
>
>
>
> vartype
> text
> parameter type
>
>
>
> source
> text
> source of the current parameter value
>
>
>
> min_val
> text
> minimum allowed value of the parameter
>
>
>
> max_val
> text
> maximum allowed value of the parameter
>
>
>
>
>
>
>
> Basic Runtime Setup
>
>
> PostgreSQL's default runtime setup is very conservative, and more appropriate to an
> old workstation than a modern server machine. As such, you will certainly want to
> change some of the runtime settings before running PostgreSQL for the first time.
> After INITDB, database administrators will want to change most or
> all of the following settings.
>
>
> In ,
> tcpip_socket and max_connections
> In ,
> shared_buffers, sort_mem, and vacuum_mem
> In , max_fsm_pages
> In , checkpoint_segments
> In ,
> effective_cache_size and random_tuple_cost
> In , syslog and possibly other logging options
>
>
>
> Please note that the configuration of a lot of the above items references "available RAM."
> Available RAM is not the total memory in your machine, but rather the amount of system
> RAM available to PostgreSQL and not being used by other applications. The distinction
> is important on systems which also run other significant software, such as a web server.
> Also, please note
> the warning regarding System V
> shared memory in before setting max_connections or shared_buffers.
>
548,551d656
<
< The
< command allows inspection of the current values of all parameters.
<
553,561d657
<
< The virtual table pg_settings
< (described in ) also allows
< displaying and updating session run-time parameters. It is equivalent
< to SHOW and SET, but can be more convenient
< to use because it can be joined with other tables, or selected from using
< any desired selection condition.
<
<
569c665
<
---
>
599a696,701
>
>
> When setting this value, keep in mind that applications which connect
> intermittently or use pooled connections will not need as many connections
> as active users.
>
742c844
<
---
>
837,838c939
< usually needed for good performance. Values of a few thousand
< are recommended for production installations. This option can
---
> usually needed for good performance. This option can
848a950,962
>
>
> The shared memory buffer is a "holding area" for PostgreSQL requests being
> fed to the kernel buffer. As such, they should always be a minority of
> available RAM. Most users doing profiling to date have reported successful
> performance with values equal to 6% to 12% of available RAM, with higher values
> being used for databases which run large complex queries or large updates
> and data transformations. The initdb script will have already set your
> shared_buffers to 1000 or the maximum supported by your
> operating system. To increase the shared memory supported,
> see .
>
>
858a973,974
>
>
867c983
< hash-based processing of IN subqueries. Because
---
> hash-based processing of IN subqueries. Because
871a988,997
>
> If you have lots of available RAM and few concurrent users, or
> if you need to run queries that pull large amounts of data and aggregates
> it, then you want a higher sort_mem. If you have
> many concurrent requests, or have many compound-complex queries with lots
> of joins and subselects, lower the sort_mem. Common settings include
> 512K for a high-concurrency web server, or 32MB for a data warehouse.
> Keep in mind that you can set this value per connection so that you can
> allocate memory differently for atypical queries.
>
884a1011,1016
>
> Users who regularly update or load large quantities of data
> may want to increase this value, possibly as mush as 64MB or 128MB
> for single-user databases. Administrators of most databases will find
> the default value sufficient.
>
903a1036,1044
>
> This number should be increased to keep pace with the quantity of
> data updated or deleted between VACUUMs. A good
> way to set it is to do periodic VACUUM VERBOSE ANALYZE,
> add up the data pages reclaimed, and make sure that your max_fsm_relations
> is greater than this amount. With a proper setting, you will be able
> to eliminate VACUUM FULL and REINDEX
> on many types of databases.
>
914c1055,1056
< The default is 1000.
---
> The default is 1000. It should be set to the total expected tables
> on all databases plus a margin of about 200 to cover the system tables.
1069c1211
<
---
>
1095a1238,1247
>
> This is possibly the most influential setting for large data loads,
> such as restore of a database. If you expect to be updating or inserting
> large quantites of data in a batch, then cautiously increase this
> parameter. When checking if you have enough disk space, beware that
> PostgreSQL may use as many as double your setting under peak load.
> Using the checkpoint_warning setting below is an
> excellent way to determine if you need to increase checkpoint_segments
> for normal use.
>
1285c1437
<
---
>
1313a1466,1471
>
> You should usually set this value to 60% to 75% of your available
> RAM, so that PostgreSQL will have an accurate idea of how much
> kernel cache there is for queries. This setting can have a dramatic
> effect on how the query planner uses indexes.
>
1327a1486,1492
>
> For database servers on modern hardware including adequate
> disk I/O, you will want to lower this value. Common settings
> are 2 or 2.5 for medium-end or multi-purpose servers, and 1.5 to 2
> for high-end dedicated hardware. The default is suitable for
> workstations.
>
1432a1598,1673
>
> Query and Index Statistics Collector
>
>
>
> STATS_START_COLLECTOR (boolean)
>
>
> Controls whether the server should start the
> statistics-collection subprocess. This is on by default, but
> may be turned off if you know you have no interest in
> collecting statistics. This option can only be set at server
> start.
>
>
>
>
>
> STATS_COMMAND_STRING (boolean)
>
>
> Enables the collection of statistics on the currently
> executing command of each session, along with the time at
> which that command began execution. This option is off by
> default. Note that even when enabled, this information is not
> visible to all users, only to superusers and the user owning
> the session being reported on; so it should not represent a
> security risk. This data can be accessed via the
> pg_stat_activity system view; refer
> to for more information.
>
>
>
>
>
> STATS_BLOCK_LEVEL (boolean)
> STATS_ROW_LEVEL (boolean)
>
>
> These enable the collection of block-level and row-level statistics
> on database activity, respectively. These options are off by
> default. This data can be accessed via the
> pg_stat and
> pg_statio family of system views;
> refer to for more information.
>
>
>
>
>
> STATS_RESET_ON_SERVER_START (boolean)
>
>
> If on, collected statistics are zeroed out whenever the server
> is restarted. If off, statistics are accumulated across server
> restarts. The default is on. This option can only be set at
> server start.
>
>
>
>
>
> DEFAULT_STATISTICS_TARGET (integer)
>
>
> Sets the default statistics target for table columns that have not
> had a column-specific target set via ALTER TABLE SET
> STATISTICS. Larger values increase the time needed to do
> ANALYZE, but may improve the quality of the planner's
> estimates. The default value is 10.
>
>
>
>
>
>
1943a2185,2205
>
>
>
>
>
>
>
>
> Statistics Logging
>
>
>
> LOG_STATEMENT_STATS (boolean)
> LOG_PARSER_STATS (boolean)
> LOG_PLANNER_STATS (boolean)
> LOG_EXECUTOR_STATS (boolean)
>
>
> For each query, write performance statistics of the respective
> module to the server log. This is a crude profiling
> instrument.
Index: installation.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/installation.sgml,v
retrieving revision 1.174
diff -r1.174 installation.sgml
1174,1176c1174,1176
< Other parameters in
< ]]>
< also affect performance.
---
> See
> ]]>
> for a list of the options which most administrators adjust.