public inbox for [email protected]
help / color / mirror / Atom feedminor documentation improvements
12+ messages / 4 participants
[nested] [flat]
* minor documentation improvements
@ 2003-09-05 00:21 Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-11 17:31 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
0 siblings, 2 replies; 12+ messages in thread
From: Neil Conway @ 2003-09-05 00:21 UTC (permalink / raw)
To: PostgreSQL Patches <[email protected]>
This patch makes a few minor improvements to the docs: make the
<varname> conventions more consistent, and improve the ANALYZE ref page.
-Neil
Attachments:
[text/x-patch] misc-doc-improvements-1.patch (12.4K, 2-misc-doc-improvements-1.patch)
download | inline diff:
Index: doc/src/sgml/perform.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/perform.sgml,v
retrieving revision 1.31
diff -c -r1.31 perform.sgml
*** doc/src/sgml/perform.sgml 31 Aug 2003 17:32:19 -0000 1.31
--- doc/src/sgml/perform.sgml 5 Sep 2003 00:15:21 -0000
***************
*** 603,609 ****
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switch-over threshold is
! set by the <varname>geqo_threshold</varname> run-time
parameter.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.
--- 603,609 ----
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switch-over threshold is
! set by the <varname>GEQO_THRESHOLD</varname> run-time
parameter.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.
Index: doc/src/sgml/plpgsql.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.22
diff -c -r1.22 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml 3 Sep 2003 22:17:07 -0000 1.22
--- doc/src/sgml/plpgsql.sgml 5 Sep 2003 00:11:49 -0000
***************
*** 1350,1356 ****
allow users to allow users to define set-returning functions
that do not have this limitation. Currently, the point at
which data begins being written to disk is controlled by the
! <varname>sort_mem</> configuration variable. Administrators
who have sufficient memory to store larger result sets in
memory should consider increasing this parameter.
</para>
--- 1350,1356 ----
allow users to allow users to define set-returning functions
that do not have this limitation. Currently, the point at
which data begins being written to disk is controlled by the
! <varname>SORT_MEM</> configuration variable. Administrators
who have sufficient memory to store larger result sets in
memory should consider increasing this parameter.
</para>
Index: doc/src/sgml/ref/analyze.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/analyze.sgml,v
retrieving revision 1.13
diff -c -r1.13 analyze.sgml
*** doc/src/sgml/ref/analyze.sgml 31 Aug 2003 17:32:21 -0000 1.13
--- doc/src/sgml/ref/analyze.sgml 5 Sep 2003 00:02:12 -0000
***************
*** 28,37 ****
<title>Description</title>
<para>
! <command>ANALYZE</command> collects statistics about the contents of
! tables in the database, and stores the results in
! the system table <literal>pg_statistic</literal>. Subsequently,
! the query planner uses the statistics to help determine the most efficient
execution plans for queries.
</para>
--- 28,37 ----
<title>Description</title>
<para>
! <command>ANALYZE</command> collects statistics about the contents
! of tables in the database, and stores the results in the system
! table <literal>pg_statistic</literal>. Subsequently, the query
! planner uses these statistics to help determine the most efficient
execution plans for queries.
</para>
***************
*** 105,153 ****
</para>
<para>
! Unlike <command>VACUUM FULL</command>,
! <command>ANALYZE</command> requires
! only a read lock on the target table, so it can run in parallel with
! other activity on the table.
</para>
<para>
! For large tables, <command>ANALYZE</command> takes a random sample of the
! table contents, rather than examining every row. This allows even very
! large tables to be analyzed in a small amount of time. Note, however,
! that the statistics are only approximate, and will change slightly each
! time <command>ANALYZE</command> is run, even if the actual table contents
! did not change. This may result in small changes in the planner's
! estimated costs shown by <command>EXPLAIN</command>.
</para>
<para>
! The collected statistics usually include a list of some of the most common
! values in each column and a histogram showing the approximate data
! distribution in each column. One or both of these may be omitted if
! <command>ANALYZE</command> deems them uninteresting (for example, in
! a unique-key column, there are no common values) or if the column
! data type does not support the appropriate operators. There is more
! information about the statistics in <xref linkend="maintenance">.
</para>
<para>
The extent of analysis can be controlled by adjusting the
! <literal>default_statistics_target</> parameter variable, or on a
! column-by-column basis by setting the per-column
! statistics target with <command>ALTER TABLE ... ALTER COLUMN ... SET
! STATISTICS</command> (see
! <xref linkend="sql-altertable" endterm="sql-altertable-title">). The
! target value sets the maximum number of entries in the most-common-value
! list and the maximum number of bins in the histogram. The default
! target value is 10, but this can be adjusted up or down to trade off
! accuracy of planner estimates against the time taken for
! <command>ANALYZE</command> and the amount of space occupied
! in <literal>pg_statistic</literal>.
! In particular, setting the statistics target to zero disables collection of
! statistics for that column. It may be useful to do that for columns that
! are never used as part of the <literal>WHERE</>, <literal>GROUP BY</>, or <literal>ORDER BY</> clauses of
! queries, since the planner will have no use for statistics on such columns.
</para>
<para>
--- 105,160 ----
</para>
<para>
! Unlike <command>VACUUM FULL</command>, <command>ANALYZE</command>
! requires only a read lock on the target table, so it can run in
! parallel with other activity on the table.
</para>
<para>
! The statistics collected by <command>ANALYZE</command> usually
! include a list of some of the most common values in each column and
! a histogram showing the approximate data distribution in each
! column. One or both of these may be omitted if
! <command>ANALYZE</command> deems them uninteresting (for example,
! in a unique-key column, there are no common values) or if the
! column data type does not support the appropriate operators. There
! is more information about the statistics in <xref
! linkend="maintenance">.
</para>
<para>
! For large tables, <command>ANALYZE</command> takes a random sample
! of the table contents, rather than examining every row. This
! allows even very large tables to be analyzed in a small amount of
! time. Note, however, that the statistics are only approximate, and
! will change slightly each time <command>ANALYZE</command> is run,
! even if the actual table contents did not change. This may result
! in small changes in the planner's estimated costs shown by
! <command>EXPLAIN</command>. In rare situations, this
! non-determinism will cause the query optimizer to choose a
! different query plan between runs of <command>ANALYZE</command>. To
! avoid this, raise the amount of statistics collected by
! <command>ANALYZE</command>, as described below.
</para>
<para>
The extent of analysis can be controlled by adjusting the
! <varname>DEFAULT_STATISTICS_TARGET</varname> parameter variable, or
! on a column-by-column basis by setting the per-column statistics
! target with <command>ALTER TABLE ... ALTER COLUMN ... SET
! STATISTICS</command> (see <xref linkend="sql-altertable"
! endterm="sql-altertable-title">). The target value sets the
! maximum number of entries in the most-common-value list and the
! maximum number of bins in the histogram. The default target value
! is 10, but this can be adjusted up or down to trade off accuracy of
! planner estimates against the time taken for
! <command>ANALYZE</command> and the amount of space occupied in
! <literal>pg_statistic</literal>. In particular, setting the
! statistics target to zero disables collection of statistics for
! that column. It may be useful to do that for columns that are
! never used as part of the <literal>WHERE</>, <literal>GROUP BY</>,
! or <literal>ORDER BY</> clauses of queries, since the planner will
! have no use for statistics on such columns.
</para>
<para>
Index: doc/src/sgml/ref/create_user.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/create_user.sgml,v
retrieving revision 1.27
diff -c -r1.27 create_user.sgml
*** doc/src/sgml/ref/create_user.sgml 31 Aug 2003 17:32:22 -0000 1.27
--- doc/src/sgml/ref/create_user.sgml 5 Sep 2003 00:08:59 -0000
***************
*** 98,104 ****
These key words control whether the password is stored
encrypted in the system catalogs. (If neither is specified,
the default behavior is determined by the configuration
! parameter <varname>password_encryption</varname>.) If the
presented password string is already in MD5-encrypted format,
then it is stored encrypted as-is, regardless of whether
<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified
--- 98,104 ----
These key words control whether the password is stored
encrypted in the system catalogs. (If neither is specified,
the default behavior is determined by the configuration
! parameter <varname>PASSWORD_ENCRYPTION</varname>.) If the
presented password string is already in MD5-encrypted format,
then it is stored encrypted as-is, regardless of whether
<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified
Index: doc/src/sgml/ref/postmaster.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/postmaster.sgml,v
retrieving revision 1.37
diff -c -r1.37 postmaster.sgml
*** doc/src/sgml/ref/postmaster.sgml 31 Aug 2003 17:32:24 -0000 1.37
--- doc/src/sgml/ref/postmaster.sgml 5 Sep 2003 00:12:50 -0000
***************
*** 376,382 ****
<listitem>
<para>
! Default value of the <literal>datestyle</literal> run-time
parameter. (The use of this environment variable is deprecated.)
</para>
</listitem>
--- 376,382 ----
<listitem>
<para>
! Default value of the <varname>DATESTYLE</varname> run-time
parameter. (The use of this environment variable is deprecated.)
</para>
</listitem>
***************
*** 563,569 ****
<prompt>$</prompt> <userinput>postmaster -c sort_mem=1234</userinput>
<prompt>$</prompt> <userinput>postmaster --sort-mem=1234</userinput>
</screen>
! Either form overrides whatever setting might exist for <literal>sort_mem</>
in <filename>postgresql.conf</>. Notice that underscores in parameter
names can be written as either underscore or dash on the command line.
</para>
--- 563,569 ----
<prompt>$</prompt> <userinput>postmaster -c sort_mem=1234</userinput>
<prompt>$</prompt> <userinput>postmaster --sort-mem=1234</userinput>
</screen>
! Either form overrides whatever setting might exist for <varname>SORT_MEM</>
in <filename>postgresql.conf</>. Notice that underscores in parameter
names can be written as either underscore or dash on the command line.
</para>
Index: doc/src/sgml/ref/reset.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/reset.sgml,v
retrieving revision 1.21
diff -c -r1.21 reset.sgml
*** doc/src/sgml/ref/reset.sgml 31 Aug 2003 17:32:24 -0000 1.21
--- doc/src/sgml/ref/reset.sgml 5 Sep 2003 00:16:07 -0000
***************
*** 93,106 ****
<title>Examples</title>
<para>
! Set <varname>datestyle</> to its default value:
<screen>
RESET datestyle;
</screen>
</para>
<para>
! Set <varname>geqo</> to its default value:
<screen>
RESET geqo;
</screen>
--- 93,106 ----
<title>Examples</title>
<para>
! Set <varname>DATESTYLE</> to its default value:
<screen>
RESET datestyle;
</screen>
</para>
<para>
! Set <varname>GEQO</> to its default value:
<screen>
RESET geqo;
</screen>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
@ 2003-09-05 20:39 ` Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
2003-09-05 23:29 ` Re: minor documentation improvements Tom Lane <[email protected]>
1 sibling, 2 replies; 12+ messages in thread
From: Peter Eisentraut @ 2003-09-05 20:39 UTC (permalink / raw)
To: Neil Conway <[email protected]>; +Cc: PostgreSQL Patches <[email protected]>
Neil Conway writes:
> This patch makes a few minor improvements to the docs: make the
> <varname> conventions more consistent,
They are consistent: They're all lowercase. Until now.
--
Peter Eisentraut [email protected]
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
@ 2003-09-05 20:58 ` Bruce Momjian <[email protected]>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 12+ messages in thread
From: Bruce Momjian @ 2003-09-05 20:58 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Neil Conway <[email protected]>; PostgreSQL Patches <[email protected]>
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > This patch makes a few minor improvements to the docs: make the
> > <varname> conventions more consistent,
>
> They are consistent: They're all lowercase. Until now.
Huh? We have been uppercasing GUC variable names in most places
already.
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
@ 2003-09-05 21:16 ` Peter Eisentraut <[email protected]>
2003-09-05 21:18 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
2003-09-05 23:24 ` Re: minor documentation improvements Neil Conway <[email protected]>
2003-09-05 23:35 ` Re: minor documentation improvements Tom Lane <[email protected]>
0 siblings, 3 replies; 12+ messages in thread
From: Peter Eisentraut @ 2003-09-05 21:16 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Neil Conway <[email protected]>; PostgreSQL Patches <[email protected]>
Bruce Momjian writes:
> Huh? We have been uppercasing GUC variable names in most places
> already.
Currently, the documentation contains about 2 GUC variable names in upper
case, the rest is lower case. (The exception are the list headings in the
main description in runtime.sgml, which are all upper case. That is a bit
inconsistent, but I think it's OK, because here they sort of serve as
section titles.) Also note that postgresql.conf, command-line option
equivalents, and SET commands all tend to use them in lower case, so that
seems like the direction to go.
--
Peter Eisentraut [email protected]
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
@ 2003-09-05 21:18 ` Bruce Momjian <[email protected]>
2 siblings, 0 replies; 12+ messages in thread
From: Bruce Momjian @ 2003-09-05 21:18 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Neil Conway <[email protected]>; PostgreSQL Patches <[email protected]>
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Huh? We have been uppercasing GUC variable names in most places
> > already.
>
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case. (The exception are the list headings in the
> main description in runtime.sgml, which are all upper case. That is a bit
> inconsistent, but I think it's OK, because here they sort of serve as
> section titles.) Also note that postgresql.conf, command-line option
> equivalents, and SET commands all tend to use them in lower case, so that
> seems like the direction to go.
Oh, OK, got it.
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
@ 2003-09-05 23:24 ` Neil Conway <[email protected]>
2003-09-06 11:29 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2 siblings, 1 reply; 12+ messages in thread
From: Neil Conway @ 2003-09-05 23:24 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Bruce Momjian <[email protected]>; PostgreSQL Patches <[email protected]>
On Fri, 2003-09-05 at 17:16, Peter Eisentraut wrote:
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case.
There are significantly more than 2 uses of upper-case GUC names in the
docs (more like 10 by my guess), but in any case, the current usage is
inconsistent.
So, is upper-case or lower-case better? I'd personally prefer
lower-case, I suppose, but I'm not too bothered either way.
-Neil
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 23:24 ` Re: minor documentation improvements Neil Conway <[email protected]>
@ 2003-09-06 11:29 ` Peter Eisentraut <[email protected]>
2003-09-10 20:05 ` Re: [PATCHES] minor documentation improvements Bruce Momjian <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2003-09-06 11:29 UTC (permalink / raw)
To: Neil Conway <[email protected]>; +Cc: Bruce Momjian <[email protected]>; PostgreSQL Patches <[email protected]>
Neil Conway writes:
> So, is upper-case or lower-case better? I'd personally prefer
> lower-case, I suppose, but I'm not too bothered either way.
If you want to change them all to lowercase, that would be fine by me. At
least it would prevent more people being confused into inconsistencies in
the future.
--
Peter Eisentraut [email protected]
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCHES] minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 23:24 ` Re: minor documentation improvements Neil Conway <[email protected]>
2003-09-06 11:29 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
@ 2003-09-10 20:05 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Bruce Momjian @ 2003-09-10 20:05 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Neil Conway <[email protected]>; pgsql-docs
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > So, is upper-case or lower-case better? I'd personally prefer
> > lower-case, I suppose, but I'm not too bothered either way.
>
> If you want to change them all to lowercase, that would be fine by me. At
> least it would prevent more people being confused into inconsistencies in
> the future.
Have we come to a conclusion here --- that we should lowercase _all_ GUC
variable references, both in runtime.sgml, SGML docs, and error
messages?
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
2003-09-05 21:16 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
@ 2003-09-05 23:35 ` Tom Lane <[email protected]>
2 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2003-09-05 23:35 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Neil Conway <[email protected]>; PostgreSQL Patches <[email protected]>
Peter Eisentraut <[email protected]> writes:
> Bruce Momjian writes:
>> Huh? We have been uppercasing GUC variable names in most places
>> already.
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case. (The exception are the list headings in the
> main description in runtime.sgml, which are all upper case. That is a bit
> inconsistent, but I think it's OK, because here they sort of serve as
> section titles.)
Okay, that seems reasonable. Ignore my prior message --- I hadn't come
across this one yet.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Re: minor documentation improvements Peter Eisentraut <[email protected]>
@ 2003-09-05 23:29 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 12+ messages in thread
From: Tom Lane @ 2003-09-05 23:29 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Neil Conway <[email protected]>; PostgreSQL Patches <[email protected]>
Peter Eisentraut <[email protected]> writes:
> Neil Conway writes:
>> This patch makes a few minor improvements to the docs: make the
>> <varname> conventions more consistent,
> They are consistent: They're all lowercase. Until now.
The varnames listed in runtime.sgml are uppercase though, no? Or were
you intending the variable definitions to be upper case and all the
references lower case? It's not real clear what the intended style is,
and I have to say that I thought Neil was heading in the intended
direction also.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
@ 2003-09-11 17:31 ` Bruce Momjian <[email protected]>
2003-09-11 18:29 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
1 sibling, 1 reply; 12+ messages in thread
From: Bruce Momjian @ 2003-09-11 17:31 UTC (permalink / raw)
To: Neil Conway <[email protected]>; +Cc: PostgreSQL Patches <[email protected]>
Patch applied. I will now go through and lowercase all the GUC
variable names, as agreed upon.
---------------------------------------------------------------------------
Neil Conway wrote:
> This patch makes a few minor improvements to the docs: make the
> <varname> conventions more consistent, and improve the ANALYZE ref page.
>
> -Neil
>
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [email protected] so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: minor documentation improvements
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-11 17:31 ` Re: minor documentation improvements Bruce Momjian <[email protected]>
@ 2003-09-11 18:29 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Bruce Momjian @ 2003-09-11 18:29 UTC (permalink / raw)
To: PostgreSQL-patches <[email protected]>; +Cc: Neil Conway <[email protected]>
Patch attached and applied.
---------------------------------------------------------------------------
Bruce Momjian wrote:
>
> Patch applied. I will now go through and lowercase all the GUC
> variable names, as agreed upon.
>
> ---------------------------------------------------------------------------
>
> Neil Conway wrote:
> > This patch makes a few minor improvements to the docs: make the
> > <varname> conventions more consistent, and improve the ANALYZE ref page.
> >
> > -Neil
> >
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to [email protected] so that your
> > message can get through to the mailing list cleanly
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> [email protected] | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/charset.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/charset.sgml,v
retrieving revision 2.38
diff -c -c -r2.38 charset.sgml
*** doc/src/sgml/charset.sgml 31 Aug 2003 17:32:18 -0000 2.38
--- doc/src/sgml/charset.sgml 11 Sep 2003 18:22:52 -0000
***************
*** 769,775 ****
<listitem>
<para>
! Using <command>SET CLIENT_ENCODING TO</command>.
Setting the client encoding can be done with this SQL command:
--- 769,775 ----
<listitem>
<para>
! Using <command>SET client_encoding TO</command>.
Setting the client encoding can be done with this SQL command:
***************
*** 786,798 ****
To query the current client encoding:
<programlisting>
! SHOW CLIENT_ENCODING;
</programlisting>
To return to the default encoding:
<programlisting>
! RESET CLIENT_ENCODING;
</programlisting>
</para>
</listitem>
--- 786,798 ----
To query the current client encoding:
<programlisting>
! SHOW client_encoding;
</programlisting>
To return to the default encoding:
<programlisting>
! RESET client_encoding;
</programlisting>
</para>
</listitem>
Index: doc/src/sgml/func.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.171
diff -c -c -r1.171 func.sgml
*** doc/src/sgml/func.sgml 11 Sep 2003 17:26:20 -0000 1.171
--- doc/src/sgml/func.sgml 11 Sep 2003 18:23:00 -0000
***************
*** 3435,3441 ****
<para>
Normally the flavor of RE being used is determined by
! <varname>REGEX_FLAVOR</>.
However, this can be overridden by a <firstterm>director</> prefix.
If an RE of any flavor begins with <literal>***:</>,
the rest of the RE is taken as an ARE.
--- 3435,3441 ----
<para>
Normally the flavor of RE being used is determined by
! <varname>regex_flavor</>.
However, this can be overridden by a <firstterm>director</> prefix.
If an RE of any flavor begins with <literal>***:</>,
the rest of the RE is taken as an ARE.
***************
*** 3762,3768 ****
While these differences are unlikely to create a problem for most
applications, you can avoid them if necessary by
! setting <varname>REGEX_FLAVOR</> to <literal>extended</>.
</para>
</sect3>
--- 3762,3768 ----
While these differences are unlikely to create a problem for most
applications, you can avoid them if necessary by
! setting <varname>regex_flavor</> to <literal>extended</>.
</para>
</sect3>
Index: doc/src/sgml/perform.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/perform.sgml,v
retrieving revision 1.32
diff -c -c -r1.32 perform.sgml
*** doc/src/sgml/perform.sgml 11 Sep 2003 17:31:45 -0000 1.32
--- doc/src/sgml/perform.sgml 11 Sep 2003 18:23:02 -0000
***************
*** 603,609 ****
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switch-over threshold is
! set by the <varname>GEQO_THRESHOLD</varname> run-time
parameter.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.
--- 603,609 ----
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switch-over threshold is
! set by the <varname>geqo_threshold</varname> run-time
parameter.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.
Index: doc/src/sgml/plpgsql.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.23
diff -c -c -r1.23 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml 11 Sep 2003 17:31:45 -0000 1.23
--- doc/src/sgml/plpgsql.sgml 11 Sep 2003 18:23:07 -0000
***************
*** 1350,1356 ****
allow users to allow users to define set-returning functions
that do not have this limitation. Currently, the point at
which data begins being written to disk is controlled by the
! <varname>SORT_MEM</> configuration variable. Administrators
who have sufficient memory to store larger result sets in
memory should consider increasing this parameter.
</para>
--- 1350,1356 ----
allow users to allow users to define set-returning functions
that do not have this limitation. Currently, the point at
which data begins being written to disk is controlled by the
! <varname>sort_mem</> configuration variable. Administrators
who have sufficient memory to store larger result sets in
memory should consider increasing this parameter.
</para>
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.205
diff -c -c -r1.205 runtime.sgml
*** doc/src/sgml/runtime.sgml 11 Sep 2003 17:27:38 -0000 1.205
--- doc/src/sgml/runtime.sgml 11 Sep 2003 18:23:12 -0000
***************
*** 630,636 ****
<variablelist>
<varlistentry>
! <term><varname>TCPIP_SOCKET</varname> (<type>boolean</type>)</term>
<listitem>
<para>
If this is true, then the server will accept TCP/IP connections.<indexterm><primary>TCP/IP</></>
--- 630,636 ----
<variablelist>
<varlistentry>
! <term><varname>tcpip_socket</varname> (<type>boolean</type>)</term>
<listitem>
<para>
If this is true, then the server will accept TCP/IP connections.<indexterm><primary>TCP/IP</></>
***************
*** 642,648 ****
</varlistentry>
<varlistentry>
! <term><varname>MAX_CONNECTIONS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Determines the maximum number of concurrent connections to the
--- 642,648 ----
</varlistentry>
<varlistentry>
! <term><varname>max_connections</varname> (<type>integer</type>)</term>
<listitem>
<para>
Determines the maximum number of concurrent connections to the
***************
*** 663,691 ****
</varlistentry>
<varlistentry>
! <term><varname>SUPERUSER_RESERVED_CONNECTIONS</varname>
(<type>integer</type>)</term>
<listitem>
<para>
Determines the number of <quote>connection slots</quote> that
are reserved for connections by <productname>PostgreSQL</>
! superusers. At most <varname>MAX_CONNECTIONS</> connections can
ever be active simultaneously. Whenever the number of active
! concurrent connections is at least <varname>MAX_CONNECTIONS</> minus
! <varname>SUPERUSER_RESERVED_CONNECTIONS</varname>, new connections
will be accepted only for superusers.
</para>
<para>
The default value is 2. The value must be less than the value of
! <varname>MAX_CONNECTIONS</varname>. This parameter can only be
set at server start.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>PORT</varname> (<type>integer</type>)</term>
<indexterm><primary>port</></>
<listitem>
<para>
--- 663,691 ----
</varlistentry>
<varlistentry>
! <term><varname>superuser_reserved_connections</varname>
(<type>integer</type>)</term>
<listitem>
<para>
Determines the number of <quote>connection slots</quote> that
are reserved for connections by <productname>PostgreSQL</>
! superusers. At most <varname>max_connections</> connections can
ever be active simultaneously. Whenever the number of active
! concurrent connections is at least <varname>max_connections</> minus
! <varname>superuser_reserved_connections</varname>, new connections
will be accepted only for superusers.
</para>
<para>
The default value is 2. The value must be less than the value of
! <varname>max_connections</varname>. This parameter can only be
set at server start.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>port</varname> (<type>integer</type>)</term>
<indexterm><primary>port</></>
<listitem>
<para>
***************
*** 697,703 ****
<varlistentry>
! <term><varname>UNIX_SOCKET_DIRECTORY</varname> (<type>string</type>)</term>
<listitem>
<para>
Specifies the directory of the Unix-domain socket on which the
--- 697,703 ----
<varlistentry>
! <term><varname>unix_socket_directory</varname> (<type>string</type>)</term>
<listitem>
<para>
Specifies the directory of the Unix-domain socket on which the
***************
*** 709,721 ****
</varlistentry>
<varlistentry>
! <term><varname>UNIX_SOCKET_GROUP</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the group owner of the Unix domain socket. (The owning
user of the socket is always the user that starts the
server.) In combination with the option
! <varname>UNIX_SOCKET_PERMISSIONS</varname> this can be used as
an additional access control mechanism for this socket type.
By default this is the empty string, which uses the default
group for the current user. This option can only be set at
--- 709,721 ----
</varlistentry>
<varlistentry>
! <term><varname>unix_socket_group</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the group owner of the Unix domain socket. (The owning
user of the socket is always the user that starts the
server.) In combination with the option
! <varname>unix_socket_permissions</varname> this can be used as
an additional access control mechanism for this socket type.
By default this is the empty string, which uses the default
group for the current user. This option can only be set at
***************
*** 725,731 ****
</varlistentry>
<varlistentry>
! <term><varname>UNIX_SOCKET_PERMISSIONS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the access permissions of the Unix domain socket. Unix
--- 725,731 ----
</varlistentry>
<varlistentry>
! <term><varname>unix_socket_permissions</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the access permissions of the Unix domain socket. Unix
***************
*** 741,747 ****
The default permissions are <literal>0777</literal>, meaning
anyone can connect. Reasonable alternatives are
<literal>0770</literal> (only user and group, see also under
! <varname>UNIX_SOCKET_GROUP</varname>) and <literal>0700</literal>
(only user). (Note that actually for a Unix domain socket, only write
permission matters and there is no point in setting or revoking
read or execute permissions.)
--- 741,747 ----
The default permissions are <literal>0777</literal>, meaning
anyone can connect. Reasonable alternatives are
<literal>0770</literal> (only user and group, see also under
! <varname>unix_socket_group</varname>) and <literal>0700</literal>
(only user). (Note that actually for a Unix domain socket, only write
permission matters and there is no point in setting or revoking
read or execute permissions.)
***************
*** 759,765 ****
</varlistentry>
<varlistentry>
! <term><varname>VIRTUAL_HOST</varname> (<type>string</type>)</term>
<listitem>
<para>
Specifies the host name or IP address on which the server is
--- 759,765 ----
</varlistentry>
<varlistentry>
! <term><varname>virtual_host</varname> (<type>string</type>)</term>
<listitem>
<para>
Specifies the host name or IP address on which the server is
***************
*** 771,777 ****
</varlistentry>
<varlistentry>
! <term><varname>RENDEZVOUS_NAME</varname> (<type>string</type>)</term>
<listitem>
<para>
Specifies the Rendezvous broadcast name. By default, the
--- 771,777 ----
</varlistentry>
<varlistentry>
! <term><varname>rendezvous_name</varname> (<type>string</type>)</term>
<listitem>
<para>
Specifies the Rendezvous broadcast name. By default, the
***************
*** 787,793 ****
<variablelist>
<varlistentry>
! <term><varname>AUTHENTICATION_TIMEOUT</varname> (<type>integer</type>)</term>
<indexterm><primary>timeout</><secondary>client authentication</></indexterm>
<indexterm><primary>client authentication</><secondary>timeout during</></indexterm>
<listitem>
--- 787,793 ----
<variablelist>
<varlistentry>
! <term><varname>authentication_timeout</varname> (<type>integer</type>)</term>
<indexterm><primary>timeout</><secondary>client authentication</></indexterm>
<indexterm><primary>client authentication</><secondary>timeout during</></indexterm>
<listitem>
***************
*** 807,813 ****
<primary>SSL</primary>
</indexterm>
! <term><varname>SSL</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables <acronym>SSL</> connections. Please read
--- 807,813 ----
<primary>SSL</primary>
</indexterm>
! <term><varname>ssl</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables <acronym>SSL</> connections. Please read
***************
*** 818,824 ****
</varlistentry>
<varlistentry>
! <term><varname>PASSWORD_ENCRYPTION</varname> (<type>boolean</type>)</term>
<listitem>
<para>
When a password is specified in <command>CREATE USER</> or
--- 818,824 ----
</varlistentry>
<varlistentry>
! <term><varname>password_encryption</varname> (<type>boolean</type>)</term>
<listitem>
<para>
When a password is specified in <command>CREATE USER</> or
***************
*** 830,836 ****
</varlistentry>
<varlistentry>
! <term><varname>KRB_SERVER_KEYFILE</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the location of the Kerberos server key file. See
--- 830,836 ----
</varlistentry>
<varlistentry>
! <term><varname>krb_server_keyfile</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the location of the Kerberos server key file. See
***************
*** 840,846 ****
</varlistentry>
<varlistentry>
! <term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
<listitem>
<para>
This allows per-database user names. It is off by default.
--- 840,846 ----
</varlistentry>
<varlistentry>
! <term><varname>db_user_namespace</varname> (<type>boolean</type>)</term>
<listitem>
<para>
This allows per-database user names. It is off by default.
***************
*** 885,891 ****
<variablelist>
<varlistentry>
! <term><varname>SHARED_BUFFERS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the number of shared memory buffers used by the database
--- 885,891 ----
<variablelist>
<varlistentry>
! <term><varname>shared_buffers</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the number of shared memory buffers used by the database
***************
*** 894,900 ****
<application>initdb</>). Each buffer is 8192 bytes, unless a
different value of <literal>BLCKSZ</> was chosen when building
the server. This setting must be at least 16, as well as at
! least twice the value of <varname>MAX_CONNECTIONS</varname>;
however, settings significantly higher than the minimum are
usually needed for good performance. Values of a few thousand
are recommended for production installations. This option can
--- 894,900 ----
<application>initdb</>). Each buffer is 8192 bytes, unless a
different value of <literal>BLCKSZ</> was chosen when building
the server. This setting must be at least 16, as well as at
! least twice the value of <varname>max_connections</varname>;
however, settings significantly higher than the minimum are
usually needed for good performance. Values of a few thousand
are recommended for production installations. This option can
***************
*** 912,918 ****
</varlistentry>
<varlistentry>
! <term><varname>SORT_MEM</varname> (<type>integer</type>)</term>
<listitem>
<para>
Specifies the amount of memory to be used by internal sort operations and
--- 912,918 ----
</varlistentry>
<varlistentry>
! <term><varname>sort_mem</varname> (<type>integer</type>)</term>
<listitem>
<para>
Specifies the amount of memory to be used by internal sort operations and
***************
*** 923,929 ****
as this value specifies before it starts to put data into temporary
files. Also, several running sessions could be doing
sort operations simultaneously. So the total memory used could be many
! times the value of <varname>SORT_MEM</varname>. Sort operations are used
by <literal>ORDER BY</>, merge joins, and <command>CREATE INDEX</>.
Hash tables are used in hash joins, hash-based aggregation, and
hash-based processing of <literal>IN</> subqueries. Because
--- 923,929 ----
as this value specifies before it starts to put data into temporary
files. Also, several running sessions could be doing
sort operations simultaneously. So the total memory used could be many
! times the value of <varname>sort_mem</varname>. Sort operations are used
by <literal>ORDER BY</>, merge joins, and <command>CREATE INDEX</>.
Hash tables are used in hash joins, hash-based aggregation, and
hash-based processing of <literal>IN</> subqueries. Because
***************
*** 934,940 ****
</varlistentry>
<varlistentry>
! <term><varname>VACUUM_MEM</varname> (<type>integer</type>)</term>
<listitem>
<para>
Specifies the maximum amount of memory to be used by
--- 934,940 ----
</varlistentry>
<varlistentry>
! <term><varname>vacuum_mem</varname> (<type>integer</type>)</term>
<listitem>
<para>
Specifies the maximum amount of memory to be used by
***************
*** 953,972 ****
<variablelist>
<varlistentry>
! <term><varname>MAX_FSM_PAGES</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum number of disk pages for which free space will
be tracked in the shared free-space map. Six bytes of shared memory
are consumed for each page slot. This setting must be more than
! 16 * <varname>MAX_FSM_RELATIONS</varname>. The default is 20000.
This option can only be set at server start.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>MAX_FSM_RELATIONS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum number of relations (tables and indexes) for which
--- 953,972 ----
<variablelist>
<varlistentry>
! <term><varname>max_fsm_pages</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum number of disk pages for which free space will
be tracked in the shared free-space map. Six bytes of shared memory
are consumed for each page slot. This setting must be more than
! 16 * <varname>max_fsm_relations</varname>. The default is 20000.
This option can only be set at server start.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>max_fsm_relations</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum number of relations (tables and indexes) for which
***************
*** 985,991 ****
<variablelist>
<varlistentry>
! <term><varname>MAX_FILES_PER_PROCESS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum number of simultaneously open files allowed to each
--- 985,991 ----
<variablelist>
<varlistentry>
! <term><varname>max_files_per_process</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum number of simultaneously open files allowed to each
***************
*** 1007,1013 ****
</varlistentry>
<varlistentry>
! <term><varname>PRELOAD_LIBRARIES</varname> (<type>string</type>)</term>
<indexterm><primary>preload_libraries</></>
<listitem>
<para>
--- 1007,1013 ----
</varlistentry>
<varlistentry>
! <term><varname>preload_libraries</varname> (<type>string</type>)</term>
<indexterm><primary>preload_libraries</></>
<listitem>
<para>
***************
*** 1066,1072 ****
<primary>fsync</primary>
</indexterm>
! <term><varname>FSYNC</varname> (<type>boolean</type>)</term>
<listitem>
<para>
If this option is on, the <productname>PostgreSQL</> server
--- 1066,1072 ----
<primary>fsync</primary>
</indexterm>
! <term><varname>fsync</varname> (<type>boolean</type>)</term>
<listitem>
<para>
If this option is on, the <productname>PostgreSQL</> server
***************
*** 1083,1089 ****
performance penalty: when a transaction is committed,
<productname>PostgreSQL</productname> must wait for the
operating system to flush the write-ahead log to disk. When
! <varname>FSYNC</varname> is disabled, the operating system is
allowed to do its best in buffering, ordering, and delaying
writes. This can result in significantly improved performance.
However, if the system crashes, the results of the last few
--- 1083,1089 ----
performance penalty: when a transaction is committed,
<productname>PostgreSQL</productname> must wait for the
operating system to flush the write-ahead log to disk. When
! <varname>fsync</varname> is disabled, the operating system is
allowed to do its best in buffering, ordering, and delaying
writes. This can result in significantly improved performance.
However, if the system crashes, the results of the last few
***************
*** 1093,1107 ****
<para>
Due to the risks involved, there is no universally correct
! setting for <varname>FSYNC</varname>. Some administrators
! always disable <varname>FSYNC</varname>, while others only
turn it off for bulk loads, where there is a clear restart
point if something goes wrong, whereas some administrators
! always leave <varname>FSYNC</varname> enabled. The default is
! to enable <varname>FSYNC</varname>, for maximum reliability.
If you trust your operating system, your hardware, and your
utility company (or your battery backup), you can consider
! disabling <varname>FSYNC</varname>.
</para>
<para>
--- 1093,1107 ----
<para>
Due to the risks involved, there is no universally correct
! setting for <varname>fsync</varname>. Some administrators
! always disable <varname>fsync</varname>, while others only
turn it off for bulk loads, where there is a clear restart
point if something goes wrong, whereas some administrators
! always leave <varname>fsync</varname> enabled. The default is
! to enable <varname>fsync</varname>, for maximum reliability.
If you trust your operating system, your hardware, and your
utility company (or your battery backup), you can consider
! disabling <varname>fsync</varname>.
</para>
<para>
***************
*** 1112,1126 ****
</varlistentry>
<varlistentry>
! <term><varname>WAL_SYNC_METHOD</varname> (<type>string</type>)</term>
<listitem>
<para>
Method used for forcing WAL updates out to disk. Possible
values are
! <literal>FSYNC</> (call <function>fsync()</> at each commit),
! <literal>FDATASYNC</> (call <function>fdatasync()</> at each commit),
! <literal>OPEN_SYNC</> (write WAL files with <function>open()</> option <symbol>O_SYNC</>), and
! <literal>OPEN_DATASYNC</> (write WAL files with <function>open()</> option <symbol>O_DSYNC</>).
Not all of these choices are available on all platforms.
This option can only be set at server start or in the
<filename>postgresql.conf</filename> file.
--- 1112,1126 ----
</varlistentry>
<varlistentry>
! <term><varname>wal_sync_method</varname> (<type>string</type>)</term>
<listitem>
<para>
Method used for forcing WAL updates out to disk. Possible
values are
! <literal>fsync</> (call <function>fsync()</> at each commit),
! <literal>fdatasync</> (call <function>fdatasync()</> at each commit),
! <literal>open_sync</> (write WAL files with <function>open()</> option <symbol>O_SYNC</>), and
! <literal>open_datasync</> (write WAL files with <function>open()</> option <symbol>O_DSYNC</>).
Not all of these choices are available on all platforms.
This option can only be set at server start or in the
<filename>postgresql.conf</filename> file.
***************
*** 1129,1135 ****
</varlistentry>
<varlistentry>
! <term><varname>WAL_BUFFERS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Number of disk-page buffers in shared memory for WAL
--- 1129,1135 ----
</varlistentry>
<varlistentry>
! <term><varname>wal_buffers</varname> (<type>integer</type>)</term>
<listitem>
<para>
Number of disk-page buffers in shared memory for WAL
***************
*** 1146,1152 ****
<variablelist>
<varlistentry>
! <term><varname>CHECKPOINT_SEGMENTS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Maximum distance between automatic WAL checkpoints, in log
--- 1146,1152 ----
<variablelist>
<varlistentry>
! <term><varname>checkpoint_segments</varname> (<type>integer</type>)</term>
<listitem>
<para>
Maximum distance between automatic WAL checkpoints, in log
***************
*** 1158,1164 ****
</varlistentry>
<varlistentry>
! <term><varname>CHECKPOINT_TIMEOUT</varname> (<type>integer</type>)</term>
<listitem>
<para>
Maximum time between automatic WAL checkpoints, in
--- 1158,1164 ----
</varlistentry>
<varlistentry>
! <term><varname>checkpoint_timeout</varname> (<type>integer</type>)</term>
<listitem>
<para>
Maximum time between automatic WAL checkpoints, in
***************
*** 1170,1176 ****
</varlistentry>
<varlistentry>
! <term><varname>CHECKPOINT_WARNING</varname> (<type>integer</type>)</term>
<listitem>
<para>
Write a message to the server logs if checkpoints caused by
--- 1170,1176 ----
</varlistentry>
<varlistentry>
! <term><varname>checkpoint_warning</varname> (<type>integer</type>)</term>
<listitem>
<para>
Write a message to the server logs if checkpoints caused by
***************
*** 1183,1189 ****
<varlistentry>
! <term><varname>COMMIT_DELAY</varname> (<type>integer</type>)</term>
<listitem>
<para>
Time delay between writing a commit record to the WAL buffer
--- 1183,1189 ----
<varlistentry>
! <term><varname>commit_delay</varname> (<type>integer</type>)</term>
<listitem>
<para>
Time delay between writing a commit record to the WAL buffer
***************
*** 1194,1200 ****
ready to commit within the given interval. But the delay is
just wasted if no other transactions become ready to
commit. Therefore, the delay is only performed if at least
! <varname>COMMIT_SIBLINGS</varname> other transactions are
active at the instant that a server process has written its
commit record. The default is zero (no delay).
</para>
--- 1194,1200 ----
ready to commit within the given interval. But the delay is
just wasted if no other transactions become ready to
commit. Therefore, the delay is only performed if at least
! <varname>commit_siblings</varname> other transactions are
active at the instant that a server process has written its
commit record. The default is zero (no delay).
</para>
***************
*** 1202,1212 ****
</varlistentry>
<varlistentry>
! <term><varname>COMMIT_SIBLINGS</varname> (<type>integer</type>)</term>
<listitem>
<para>
Minimum number of concurrent open transactions to require
! before performing the <varname>COMMIT_DELAY</> delay. A larger
value makes it more probable that at least one other
transaction will become ready to commit during the delay
interval. The default is five.
--- 1202,1212 ----
</varlistentry>
<varlistentry>
! <term><varname>commit_siblings</varname> (<type>integer</type>)</term>
<listitem>
<para>
Minimum number of concurrent open transactions to require
! before performing the <varname>commit_delay</> delay. A larger
value makes it more probable that at least one other
transaction will become ready to commit during the delay
interval. The default is five.
***************
*** 1243,1249 ****
<variablelist>
<varlistentry>
! <term><varname>ENABLE_HASHAGG</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of hashed
--- 1243,1249 ----
<variablelist>
<varlistentry>
! <term><varname>enable_hashagg</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of hashed
***************
*** 1254,1260 ****
</varlistentry>
<varlistentry>
! <term><varname>ENABLE_HASHJOIN</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of hash-join plan
--- 1254,1260 ----
</varlistentry>
<varlistentry>
! <term><varname>enable_hashjoin</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of hash-join plan
***************
*** 1269,1275 ****
<primary>index scan</primary>
</indexterm>
! <term><varname>ENABLE_INDEXSCAN</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of index-scan plan
--- 1269,1275 ----
<primary>index scan</primary>
</indexterm>
! <term><varname>enable_indexscan</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of index-scan plan
***************
*** 1280,1286 ****
</varlistentry>
<varlistentry>
! <term><varname>ENABLE_MERGEJOIN</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of merge-join plan
--- 1280,1286 ----
</varlistentry>
<varlistentry>
! <term><varname>enable_mergejoin</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of merge-join plan
***************
*** 1291,1297 ****
</varlistentry>
<varlistentry>
! <term><varname>ENABLE_NESTLOOP</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of nested-loop join
--- 1291,1297 ----
</varlistentry>
<varlistentry>
! <term><varname>enable_nestloop</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of nested-loop join
***************
*** 1308,1314 ****
<primary>sequential scan</primary>
</indexterm>
! <term><varname>ENABLE_SEQSCAN</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of sequential scan
--- 1308,1314 ----
<primary>sequential scan</primary>
</indexterm>
! <term><varname>enable_seqscan</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of sequential scan
***************
*** 1321,1327 ****
</varlistentry>
<varlistentry>
! <term><varname>ENABLE_SORT</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of explicit sort
--- 1321,1327 ----
</varlistentry>
<varlistentry>
! <term><varname>enable_sort</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of explicit sort
***************
*** 1334,1340 ****
</varlistentry>
<varlistentry>
! <term><varname>ENABLE_TIDSCAN</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of <acronym>TID</>
--- 1334,1340 ----
</varlistentry>
<varlistentry>
! <term><varname>enable_tidscan</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables the query planner's use of <acronym>TID</>
***************
*** 1363,1369 ****
<variablelist>
<varlistentry>
! <term><varname>EFFECTIVE_CACHE_SIZE</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the planner's assumption about the effective size of the
--- 1363,1369 ----
<variablelist>
<varlistentry>
! <term><varname>effective_cache_size</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the planner's assumption about the effective size of the
***************
*** 1376,1382 ****
</varlistentry>
<varlistentry>
! <term><varname>RANDOM_PAGE_COST</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the query planner's estimate of the cost of a
--- 1376,1382 ----
</varlistentry>
<varlistentry>
! <term><varname>random_page_cost</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the query planner's estimate of the cost of a
***************
*** 1389,1395 ****
</varlistentry>
<varlistentry>
! <term><varname>CPU_TUPLE_COST</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the query planner's estimate of the cost of processing
--- 1389,1395 ----
</varlistentry>
<varlistentry>
! <term><varname>cpu_tuple_cost</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the query planner's estimate of the cost of processing
***************
*** 1400,1406 ****
</varlistentry>
<varlistentry>
! <term><varname>CPU_INDEX_TUPLE_COST</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the query planner's estimate of the cost of processing
--- 1400,1406 ----
</varlistentry>
<varlistentry>
! <term><varname>cpu_index_tuple_cost</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the query planner's estimate of the cost of processing
***************
*** 1411,1417 ****
</varlistentry>
<varlistentry>
! <term><varname>CPU_OPERATOR_COST</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the planner's estimate of the cost of processing each
--- 1411,1417 ----
</varlistentry>
<varlistentry>
! <term><varname>cpu_operator_cost</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Sets the planner's estimate of the cost of processing each
***************
*** 1437,1455 ****
<primary>GEQO</primary>
<see>genetic query optimization</see>
</indexterm>
! <term><varname>GEQO</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables genetic query optimization, which is an
algorithm that attempts to do query planning without exhaustive
searching. This is on by default. See also the various other
! <varname>GEQO_</varname> settings.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>GEQO_THRESHOLD</varname> (<type>integer</type>)</term>
<listitem>
<para>
Use genetic query optimization to plan queries with at least
--- 1437,1455 ----
<primary>GEQO</primary>
<see>genetic query optimization</see>
</indexterm>
! <term><varname>geqo</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables or disables genetic query optimization, which is an
algorithm that attempts to do query planning without exhaustive
searching. This is on by default. See also the various other
! <varname>geqo_</varname> settings.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>geqo_threshold</varname> (<type>integer</type>)</term>
<listitem>
<para>
Use genetic query optimization to plan queries with at least
***************
*** 1463,1472 ****
</varlistentry>
<varlistentry>
! <term><varname>GEQO_EFFORT</varname> (<type>integer</type>)</term>
! <term><varname>GEQO_GENERATIONS</varname> (<type>integer</type>)</term>
! <term><varname>GEQO_POOL_SIZE</varname> (<type>integer</type>)</term>
! <term><varname>GEQO_SELECTION_BIAS</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Various tuning parameters for the genetic query optimization
--- 1463,1472 ----
</varlistentry>
<varlistentry>
! <term><varname>geqo_effort</varname> (<type>integer</type>)</term>
! <term><varname>geqo_generations</varname> (<type>integer</type>)</term>
! <term><varname>geqo_pool_size</varname> (<type>integer</type>)</term>
! <term><varname>geqo_selection_bias</varname> (<type>floating point</type>)</term>
<listitem>
<para>
Various tuning parameters for the genetic query optimization
***************
*** 1495,1501 ****
<variablelist>
<varlistentry>
! <term><varname>DEFAULT_STATISTICS_TARGET</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the default statistics target for table columns that have not
--- 1495,1501 ----
<variablelist>
<varlistentry>
! <term><varname>default_statistics_target</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the default statistics target for table columns that have not
***************
*** 1508,1533 ****
</varlistentry>
<varlistentry>
! <term><varname>FROM_COLLAPSE_LIMIT</varname> (<type>integer</type>)</term>
<listitem>
<para>
The planner will merge sub-queries into upper queries if the resulting
FROM list would have no more than this many items. Smaller values
reduce planning time but may yield inferior query plans.
The default is 8. It is usually wise to keep this less than
! <literal>GEQO_THRESHOLD</>.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>JOIN_COLLAPSE_LIMIT</varname> (<type>integer</type>)</term>
<listitem>
<para>
The planner will flatten explicit inner <literal>JOIN</> constructs
into lists of <literal>FROM</> items whenever a list of no more than
this many items would result. Usually this is set the same as
! <literal>FROM_COLLAPSE_LIMIT</>. Setting it to 1 prevents any
flattening of inner <literal>JOIN</>s, allowing explicit
<literal>JOIN</> syntax to be used to control the join order.
Intermediate values might be useful to trade off planning time
--- 1508,1533 ----
</varlistentry>
<varlistentry>
! <term><varname>from_collapse_limit</varname> (<type>integer</type>)</term>
<listitem>
<para>
The planner will merge sub-queries into upper queries if the resulting
FROM list would have no more than this many items. Smaller values
reduce planning time but may yield inferior query plans.
The default is 8. It is usually wise to keep this less than
! <varname>geqo_threshold</varname>.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>join_collapse_limit</varname> (<type>integer</type>)</term>
<listitem>
<para>
The planner will flatten explicit inner <literal>JOIN</> constructs
into lists of <literal>FROM</> items whenever a list of no more than
this many items would result. Usually this is set the same as
! <varname>from_collapse_limit</>. Setting it to 1 prevents any
flattening of inner <literal>JOIN</>s, allowing explicit
<literal>JOIN</> syntax to be used to control the join order.
Intermediate values might be useful to trade off planning time
***************
*** 1557,1563 ****
<variablelist>
<varlistentry>
! <term><varname>SYSLOG</varname> (<type>integer</type>)</term>
<listitem>
<para>
<productname>PostgreSQL</productname> allows the use of
--- 1557,1563 ----
<variablelist>
<varlistentry>
! <term><varname>syslog</varname> (<type>integer</type>)</term>
<listitem>
<para>
<productname>PostgreSQL</productname> allows the use of
***************
*** 1573,1579 ****
</varlistentry>
<varlistentry>
! <term><varname>SYSLOG_FACILITY</varname> (<type>string</type>)</term>
<listitem>
<para>
This option determines the <application>syslog</application>
--- 1573,1579 ----
</varlistentry>
<varlistentry>
! <term><varname>syslog_facility</varname> (<type>string</type>)</term>
<listitem>
<para>
This option determines the <application>syslog</application>
***************
*** 1590,1596 ****
</varlistentry>
<varlistentry>
! <term><varname>SYSLOG_IDENT</varname> (<type>string</type>)</term>
<listitem>
<para>
If logging to <application>syslog</> is enabled, this option
--- 1590,1596 ----
</varlistentry>
<varlistentry>
! <term><varname>syslog_ident</varname> (<type>string</type>)</term>
<listitem>
<para>
If logging to <application>syslog</> is enabled, this option
***************
*** 1610,1616 ****
<variablelist>
<varlistentry>
! <term><varname>CLIENT_MIN_MESSAGES</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls which message levels are sent to the client.
--- 1610,1616 ----
<variablelist>
<varlistentry>
! <term><varname>client_min_messages</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls which message levels are sent to the client.
***************
*** 1621,1633 ****
includes all the levels that follow it. The later the level,
the fewer messages are sent. The default is
<literal>NOTICE</>. Note that <literal>LOG</> has a different
! rank here than in <literal>LOG_MIN_MESSAGES</>.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>LOG_MIN_MESSAGES</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls which message levels are written to the server log.
--- 1621,1633 ----
includes all the levels that follow it. The later the level,
the fewer messages are sent. The default is
<literal>NOTICE</>. Note that <literal>LOG</> has a different
! rank here than in <varname>log_min_messages</>.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>log_min_messages</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls which message levels are written to the server log.
***************
*** 1639,1664 ****
follow it. The later the level, the fewer messages are sent
to the log. The default is <literal>NOTICE</>. Note that
<literal>LOG</> has a different rank here than in
! <literal>CLIENT_MIN_MESSAGES</>.
Only superusers can increase this option.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>LOG_ERROR_VERBOSITY</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls the amount of detail written in the server log for each
! message that is logged. Valid values are <literal>TERSE</>,
! <literal>DEFAULT</>, and <literal>VERBOSE</>, each adding more
fields to displayed messages.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>LOG_MIN_ERROR_STATEMENT</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls whether or not the SQL statement that causes an error
--- 1639,1664 ----
follow it. The later the level, the fewer messages are sent
to the log. The default is <literal>NOTICE</>. Note that
<literal>LOG</> has a different rank here than in
! <varname>client_min_messages</>.
Only superusers can increase this option.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>log_error_verbosity</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls the amount of detail written in the server log for each
! message that is logged. Valid values are <literal>terse</>,
! <literal>default</>, and <literal>verbose</>, each adding more
fields to displayed messages.
</para>
</listitem>
</varlistentry>
<varlistentry>
! <term><varname>log_min_error_statement</varname> (<type>string</type>)</term>
<listitem>
<para>
Controls whether or not the SQL statement that causes an error
***************
*** 1682,1688 ****
</varlistentry>
<varlistentry>
! <term><varname>LOG_MIN_DURATION_STATEMENT</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets a minimum statement execution time (in milliseconds)
--- 1682,1688 ----
</varlistentry>
<varlistentry>
! <term><varname>log_min_duration_statement</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets a minimum statement execution time (in milliseconds)
***************
*** 1701,1707 ****
</varlistentry>
<varlistentry>
! <term><varname>SILENT_MODE</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Runs the server silently. If this option is set, the server
--- 1701,1707 ----
</varlistentry>
<varlistentry>
! <term><varname>silent_mode</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Runs the server silently. If this option is set, the server
***************
*** 1807,1816 ****
<variablelist>
<varlistentry>
! <term><varname>DEBUG_PRINT_PARSE</varname> (<type>boolean</type>)</term>
! <term><varname>DEBUG_PRINT_REWRITTEN</varname> (<type>boolean</type>)</term>
! <term><varname>DEBUG_PRINT_PLAN</varname> (<type>boolean</type>)</term>
! <term><varname>DEBUG_PRETTY_PRINT</varname> (<type>boolean</type>)</term>
<listitem>
<para>
These options enable various debugging output to be sent to the
--- 1807,1816 ----
<variablelist>
<varlistentry>
! <term><varname>debug_print_parse</varname> (<type>boolean</type>)</term>
! <term><varname>debug_print_rewritten</varname> (<type>boolean</type>)</term>
! <term><varname>debug_print_plan</varname> (<type>boolean</type>)</term>
! <term><varname>debug_pretty_print</varname> (<type>boolean</type>)</term>
<listitem>
<para>
These options enable various debugging output to be sent to the
***************
*** 1826,1832 ****
</varlistentry>
<varlistentry>
! <term><varname>LOG_CONNECTIONS</varname> (<type>boolean</type>)</term>
<listitem>
<para>
This outputs a line to the server logs detailing each successful
--- 1826,1832 ----
</varlistentry>
<varlistentry>
! <term><varname>log_connections</varname> (<type>boolean</type>)</term>
<listitem>
<para>
This outputs a line to the server logs detailing each successful
***************
*** 1839,1850 ****
<varlistentry>
! <term><varname>LOG_DURATION</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Causes the duration of every completed statement to be logged.
! To use this option, enable <varname>LOG_STATEMENT</> and
! <varname>LOG_PID</> so you can link the statement to the
duration using the process ID.
Only superusers can turn off this option if it is enabled by
the administrator.
--- 1839,1850 ----
<varlistentry>
! <term><varname>log_duration</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Causes the duration of every completed statement to be logged.
! To use this option, enable <varname>log_statement</> and
! <varname>log_pid</> so you can link the statement to the
duration using the process ID.
Only superusers can turn off this option if it is enabled by
the administrator.
***************
*** 1853,1859 ****
</varlistentry>
<varlistentry>
! <term><varname>LOG_PID</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Prefixes each message in the server log file with the process ID of
--- 1853,1859 ----
</varlistentry>
<varlistentry>
! <term><varname>log_pid</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Prefixes each message in the server log file with the process ID of
***************
*** 1866,1872 ****
</varlistentry>
<varlistentry>
! <term><varname>LOG_STATEMENT</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Causes each SQL statement to be logged.
--- 1866,1872 ----
</varlistentry>
<varlistentry>
! <term><varname>log_statement</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Causes each SQL statement to be logged.
***************
*** 1877,1883 ****
</varlistentry>
<varlistentry>
! <term><varname>LOG_TIMESTAMP</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Prefixes each server log message with a time stamp. The default
--- 1877,1883 ----
</varlistentry>
<varlistentry>
! <term><varname>log_timestamp</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Prefixes each server log message with a time stamp. The default
***************
*** 1887,1893 ****
</varlistentry>
<varlistentry>
! <term><varname>LOG_HOSTNAME</varname> (<type>boolean</type>)</term>
<listitem>
<para>
By default, connection logs only show the IP address of the
--- 1887,1893 ----
</varlistentry>
<varlistentry>
! <term><varname>log_hostname</varname> (<type>boolean</type>)</term>
<listitem>
<para>
By default, connection logs only show the IP address of the
***************
*** 1900,1906 ****
</varlistentry>
<varlistentry>
! <term><varname>LOG_SOURCE_PORT</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Shows the outgoing port number of the connecting host in the
--- 1900,1906 ----
</varlistentry>
<varlistentry>
! <term><varname>log_source_port</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Shows the outgoing port number of the connecting host in the
***************
*** 1924,1933 ****
<variablelist>
<varlistentry>
! <term><varname>LOG_STATEMENT_STATS</varname> (<type>boolean</type>)</term>
! <term><varname>LOG_PARSER_STATS</varname> (<type>boolean</type>)</term>
! <term><varname>LOG_PLANNER_STATS</varname> (<type>boolean</type>)</term>
! <term><varname>LOG_EXECUTOR_STATS</varname> (<type>boolean</type>)</term>
<listitem>
<para>
For each query, write performance statistics of the respective
--- 1924,1933 ----
<variablelist>
<varlistentry>
! <term><varname>log_statement_stats</varname> (<type>boolean</type>)</term>
! <term><varname>log_parser_stats</varname> (<type>boolean</type>)</term>
! <term><varname>log_planner_stats</varname> (<type>boolean</type>)</term>
! <term><varname>log_executor_stats</varname> (<type>boolean</type>)</term>
<listitem>
<para>
For each query, write performance statistics of the respective
***************
*** 1947,1953 ****
<variablelist>
<varlistentry>
! <term><varname>STATS_START_COLLECTOR</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Controls whether the server should start the
--- 1947,1953 ----
<variablelist>
<varlistentry>
! <term><varname>stats_start_collector</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Controls whether the server should start the
***************
*** 1960,1966 ****
</varlistentry>
<varlistentry>
! <term><varname>STATS_COMMAND_STRING</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables the collection of statistics on the currently
--- 1960,1966 ----
</varlistentry>
<varlistentry>
! <term><varname>stats_command_string</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Enables the collection of statistics on the currently
***************
*** 1977,1984 ****
</varlistentry>
<varlistentry>
! <term><varname>STATS_BLOCK_LEVEL</varname> (<type>boolean</type>)</term>
! <term><varname>STATS_ROW_LEVEL</varname> (<type>boolean</type>)</term>
<listitem>
<para>
These enable the collection of block-level and row-level statistics
--- 1977,1984 ----
</varlistentry>
<varlistentry>
! <term><varname>stats_block_level</varname> (<type>boolean</type>)</term>
! <term><varname>stats_row_level</varname> (<type>boolean</type>)</term>
<listitem>
<para>
These enable the collection of block-level and row-level statistics
***************
*** 1992,1998 ****
</varlistentry>
<varlistentry>
! <term><varname>STATS_RESET_ON_SERVER_START</varname> (<type>boolean</type>)</term>
<listitem>
<para>
If on, collected statistics are zeroed out whenever the server
--- 1992,1998 ----
</varlistentry>
<varlistentry>
! <term><varname>stats_reset_on_server_start</varname> (<type>boolean</type>)</term>
<listitem>
<para>
If on, collected statistics are zeroed out whenever the server
***************
*** 2015,2021 ****
<variablelist>
<varlistentry>
! <term><varname>SEARCH_PATH</varname> (<type>string</type>)</term>
<indexterm><primary>search_path</></>
<indexterm><primary>path</><secondary>for schemas</></>
<listitem>
--- 2015,2021 ----
<variablelist>
<varlistentry>
! <term><varname>search_path</varname> (<type>string</type>)</term>
<indexterm><primary>search_path</></>
<indexterm><primary>path</><secondary>for schemas</></>
<listitem>
***************
*** 2030,2036 ****
</para>
<para>
! The value for <varname>SEARCH_PATH</varname> has to be a comma-separated
list of schema names. If one of the list items is
the special value <literal>$user</literal>, then the schema
having the name returned by <function>SESSION_USER</> is substituted, if there
--- 2030,2036 ----
</para>
<para>
! The value for <varname>search_path</varname> has to be a comma-separated
list of schema names. If one of the list items is
the special value <literal>$user</literal>, then the schema
having the name returned by <function>SESSION_USER</> is substituted, if there
***************
*** 2070,2078 ****
The current effective value of the search path can be examined
via the <acronym>SQL</acronym> function
<function>current_schemas()</>. This is not quite the same as
! examining the value of <varname>SEARCH_PATH</varname>, since
<function>current_schemas()</> shows how the requests
! appearing in <varname>SEARCH_PATH</varname> were resolved.
</para>
<para>
--- 2070,2078 ----
The current effective value of the search path can be examined
via the <acronym>SQL</acronym> function
<function>current_schemas()</>. This is not quite the same as
! examining the value of <varname>search_path</varname>, since
<function>current_schemas()</> shows how the requests
! appearing in <varname>search_path</varname> were resolved.
</para>
<para>
***************
*** 2087,2093 ****
<primary>transaction isolation level</primary>
</indexterm>
! <term><varname>DEFAULT_TRANSACTION_ISOLATION</varname> (<type>string</type>)</term>
<listitem>
<para>
Each SQL transaction has an isolation level, which can be either
--- 2087,2093 ----
<primary>transaction isolation level</primary>
</indexterm>
! <term><varname>default_transaction_isolation</varname> (<type>string</type>)</term>
<listitem>
<para>
Each SQL transaction has an isolation level, which can be either
***************
*** 2108,2114 ****
<primary>read-only transaction</primary>
</indexterm>
! <term><varname>DEFAULT_TRANSACTION_READ_ONLY</varname> (<type>boolean</type>)</term>
<listitem>
<para>
A read-only SQL transaction cannot alter non-temporary tables.
--- 2108,2114 ----
<primary>read-only transaction</primary>
</indexterm>
! <term><varname>default_transaction_read_only</varname> (<type>boolean</type>)</term>
<listitem>
<para>
A read-only SQL transaction cannot alter non-temporary tables.
***************
*** 2123,2129 ****
</varlistentry>
<varlistentry>
! <term><varname>STATEMENT_TIMEOUT</varname> (<type>integer</type>)</term>
<listitem>
<para>
Aborts any statement that takes over the specified number of
--- 2123,2129 ----
</varlistentry>
<varlistentry>
! <term><varname>statement_timeout</varname> (<type>integer</type>)</term>
<listitem>
<para>
Aborts any statement that takes over the specified number of
***************
*** 2140,2146 ****
<variablelist>
<varlistentry>
! <term><varname>DATESTYLE</varname> (<type>string</type>)</term>
<indexterm><primary>date style</></>
<listitem>
<para>
--- 2140,2146 ----
<variablelist>
<varlistentry>
! <term><varname>datestyle</varname> (<type>string</type>)</term>
<indexterm><primary>date style</></>
<listitem>
<para>
***************
*** 2161,2167 ****
</varlistentry>
<varlistentry>
! <term><varname>TIMEZONE</varname> (<type>string</type>)</term>
<indexterm><primary>time zone</></>
<listitem>
<para>
--- 2161,2167 ----
</varlistentry>
<varlistentry>
! <term><varname>timezone</varname> (<type>string</type>)</term>
<indexterm><primary>time zone</></>
<listitem>
<para>
***************
*** 2174,2180 ****
</varlistentry>
<varlistentry>
! <term><varname>AUSTRALIAN_TIMEZONES</varname> (<type>boolean</type>)</term>
<indexterm><primary>time zone</><secondary>Australian</></>
<listitem>
<para>
--- 2174,2180 ----
</varlistentry>
<varlistentry>
! <term><varname>australian_timezones</varname> (<type>boolean</type>)</term>
<indexterm><primary>time zone</><secondary>Australian</></>
<listitem>
<para>
***************
*** 2196,2202 ****
<secondary>display</secondary>
</indexterm>
! <term><varname>EXTRA_FLOAT_DIGITS</varname> (<type>integer</type>)</term>
<listitem>
<para>
This parameter adjusts the number of digits displayed for
--- 2196,2202 ----
<secondary>display</secondary>
</indexterm>
! <term><varname>extra_float_digits</varname> (<type>integer</type>)</term>
<listitem>
<para>
This parameter adjusts the number of digits displayed for
***************
*** 2212,2218 ****
</varlistentry>
<varlistentry>
! <term><varname>CLIENT_ENCODING</varname> (<type>string</type>)</term>
<indexterm><primary>character set</></>
<listitem>
<para>
--- 2212,2218 ----
</varlistentry>
<varlistentry>
! <term><varname>client_encoding</varname> (<type>string</type>)</term>
<indexterm><primary>character set</></>
<listitem>
<para>
***************
*** 2223,2229 ****
</varlistentry>
<varlistentry>
! <term><varname>LC_MESSAGES</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the language in which messages are displayed. Acceptable
--- 2223,2229 ----
</varlistentry>
<varlistentry>
! <term><varname>lc_messages</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the language in which messages are displayed. Acceptable
***************
*** 2244,2250 ****
</varlistentry>
<varlistentry>
! <term><varname>LC_MONETARY</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the locale to use for formatting monetary amounts, for
--- 2244,2250 ----
</varlistentry>
<varlistentry>
! <term><varname>lc_monetary</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the locale to use for formatting monetary amounts, for
***************
*** 2259,2265 ****
</varlistentry>
<varlistentry>
! <term><varname>LC_NUMERIC</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the locale to use for formatting numbers, for example
--- 2259,2265 ----
</varlistentry>
<varlistentry>
! <term><varname>lc_numeric</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the locale to use for formatting numbers, for example
***************
*** 2274,2280 ****
</varlistentry>
<varlistentry>
! <term><varname>LC_TIME</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the locale to use for formatting date and time values.
--- 2274,2280 ----
</varlistentry>
<varlistentry>
! <term><varname>lc_time</varname> (<type>string</type>)</term>
<listitem>
<para>
Sets the locale to use for formatting date and time values.
***************
*** 2297,2303 ****
<variablelist>
<varlistentry>
! <term><varname>EXPLAIN_PRETTY_PRINT</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Determines whether <command>EXPLAIN VERBOSE</> uses the indented
--- 2297,2303 ----
<variablelist>
<varlistentry>
! <term><varname>explain_pretty_print</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Determines whether <command>EXPLAIN VERBOSE</> uses the indented
***************
*** 2307,2313 ****
</varlistentry>
<varlistentry>
! <term><varname>DYNAMIC_LIBRARY_PATH</varname> (<type>string</type>)</term>
<indexterm><primary>dynamic_library_path</></>
<indexterm><primary>dynamic loading</></>
<listitem>
--- 2307,2313 ----
</varlistentry>
<varlistentry>
! <term><varname>dynamic_library_path</varname> (<type>string</type>)</term>
<indexterm><primary>dynamic_library_path</></>
<indexterm><primary>dynamic loading</></>
<listitem>
***************
*** 2321,2327 ****
</para>
<para>
! The value for <varname>DYNAMIC_LIBRARY_PATH</varname> has to be a colon-separated
list of absolute directory names. If a directory name starts
with the special value <literal>$libdir</literal>, the
compiled-in <productname>PostgreSQL</productname> package
--- 2321,2327 ----
</para>
<para>
! The value for <varname>dynamic_library_path</varname> has to be a colon-separated
list of absolute directory names. If a directory name starts
with the special value <literal>$libdir</literal>, the
compiled-in <productname>PostgreSQL</productname> package
***************
*** 2353,2359 ****
</varlistentry>
<varlistentry>
! <term><varname>MAX_EXPR_DEPTH</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum expression nesting depth of the parser. The
--- 2353,2359 ----
</varlistentry>
<varlistentry>
! <term><varname>max_expr_depth</varname> (<type>integer</type>)</term>
<listitem>
<para>
Sets the maximum expression nesting depth of the parser. The
***************
*** 2383,2389 ****
<secondary>deadlock</secondary>
</indexterm>
! <term><varname>DEADLOCK_TIMEOUT</varname> (<type>integer</type>)</term>
<listitem>
<para>
This is the amount of time, in milliseconds, to wait on a lock
--- 2383,2389 ----
<secondary>deadlock</secondary>
</indexterm>
! <term><varname>deadlock_timeout</varname> (<type>integer</type>)</term>
<listitem>
<para>
This is the amount of time, in milliseconds, to wait on a lock
***************
*** 2405,2416 ****
</varlistentry>
<varlistentry>
! <term><varname>MAX_LOCKS_PER_TRANSACTION</varname> (<type>integer</type>)</term>
<listitem>
<para>
The shared lock table is sized on the assumption that at most
! <varname>MAX_LOCKS_PER_TRANSACTION</> *
! <varname>MAX_CONNECTIONS</varname> distinct objects will need to
be locked at any one time. The default, 64, has historically
proven sufficient, but you might need to raise this value if you
have clients that touch many different tables in a single
--- 2405,2416 ----
</varlistentry>
<varlistentry>
! <term><varname>max_locks_per_transaction</varname> (<type>integer</type>)</term>
<listitem>
<para>
The shared lock table is sized on the assumption that at most
! <varname>max_locks_per_transaction</> *
! <varname>max_connections</varname> distinct objects will need to
be locked at any one time. The default, 64, has historically
proven sufficient, but you might need to raise this value if you
have clients that touch many different tables in a single
***************
*** 2430,2436 ****
<variablelist>
<varlistentry>
! <term><varname>ADD_MISSING_FROM</varname> (<type>boolean</type>)</term>
<indexterm><primary>FROM</><secondary>missing</></>
<listitem>
<para>
--- 2430,2436 ----
<variablelist>
<varlistentry>
! <term><varname>add_missing_from</varname> (<type>boolean</type>)</term>
<indexterm><primary>FROM</><secondary>missing</></>
<listitem>
<para>
***************
*** 2447,2453 ****
</varlistentry>
<varlistentry>
! <term><varname>REGEX_FLAVOR</varname> (<type>string</type>)</term>
<indexterm><primary>regular expressions</></>
<listitem>
<para>
--- 2447,2453 ----
</varlistentry>
<varlistentry>
! <term><varname>regex_flavor</varname> (<type>string</type>)</term>
<indexterm><primary>regular expressions</></>
<listitem>
<para>
***************
*** 2461,2467 ****
</varlistentry>
<varlistentry>
! <term><varname>SQL_INHERITANCE</varname> (<type>boolean</type>)</term>
<indexterm><primary>inheritance</></>
<listitem>
<para>
--- 2461,2467 ----
</varlistentry>
<varlistentry>
! <term><varname>sql_inheritance</varname> (<type>boolean</type>)</term>
<indexterm><primary>inheritance</></>
<listitem>
<para>
***************
*** 2483,2489 ****
<variablelist>
<varlistentry>
! <term><varname>TRANSFORM_NULL_EQUALS</varname> (<type>boolean</type>)</term>
<indexterm><primary>IS NULL</></>
<listitem>
<para>
--- 2483,2489 ----
<variablelist>
<varlistentry>
! <term><varname>transform_null_equals</varname> (<type>boolean</type>)</term>
<indexterm><primary>IS NULL</></>
<listitem>
<para>
***************
*** 2544,2550 ****
<variablelist>
<varlistentry>
! <term><varname>DEBUG_ASSERTIONS</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Turns on various assertion checks. This is a debugging aid. If
--- 2544,2550 ----
<variablelist>
<varlistentry>
! <term><varname>debug_assertions</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Turns on various assertion checks. This is a debugging aid. If
***************
*** 2562,2568 ****
</varlistentry>
<varlistentry>
! <term><varname>PRE_AUTH_DELAY</varname> (<type>integer</type>)</term>
<listitem>
<para>
If nonzero, a delay of this many seconds occurs just after a new
--- 2562,2568 ----
</varlistentry>
<varlistentry>
! <term><varname>pre_auth_delay</varname> (<type>integer</type>)</term>
<listitem>
<para>
If nonzero, a delay of this many seconds occurs just after a new
***************
*** 2575,2581 ****
</varlistentry>
<varlistentry>
! <term><varname>TRACE_NOTIFY</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Generates a great amount of debugging output for the
--- 2575,2581 ----
</varlistentry>
<varlistentry>
! <term><varname>trace_notify</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Generates a great amount of debugging output for the
***************
*** 2589,2601 ****
</varlistentry>
<varlistentry>
! <term><varname>TRACE_LOCKS</varname> (<type>boolean</type>)</term>
! <term><varname>TRACE_LWLOCKS</varname> (<type>boolean</type>)</term>
! <term><varname>TRACE_USERLOCKS</varname> (<type>boolean</type>)</term>
! <term><varname>TRACE_LOCK_OIDMIN</varname> (<type>boolean</type>)</term>
! <term><varname>TRACE_LOCK_TABLE</varname> (<type>boolean</type>)</term>
! <term><varname>DEBUG_DEADLOCKS</varname> (<type>boolean</type>)</term>
! <term><varname>LOG_BTREE_BUILD_STATS</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Various other code tracing and debugging options.
--- 2589,2601 ----
</varlistentry>
<varlistentry>
! <term><varname>trace_locks</varname> (<type>boolean</type>)</term>
! <term><varname>trace_lwlocks</varname> (<type>boolean</type>)</term>
! <term><varname>trace_userlocks</varname> (<type>boolean</type>)</term>
! <term><varname>trace_lock_oidmin</varname> (<type>boolean</type>)</term>
! <term><varname>trace_lock_table</varname> (<type>boolean</type>)</term>
! <term><varname>debug_deadlocks</varname> (<type>boolean</type>)</term>
! <term><varname>log_btree_build_stats</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Various other code tracing and debugging options.
***************
*** 2604,2610 ****
</varlistentry>
<varlistentry>
! <term><varname>WAL_DEBUG</varname> (<type>integer</type>)</term>
<listitem>
<para>
If nonzero, turn on WAL-related debugging output.
--- 2604,2610 ----
</varlistentry>
<varlistentry>
! <term><varname>wal_debug</varname> (<type>integer</type>)</term>
<listitem>
<para>
If nonzero, turn on WAL-related debugging output.
***************
*** 2613,2624 ****
</varlistentry>
<varlistentry>
! <term><varname>ZERO_DAMAGED_PAGES</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Detection of a damaged page header normally causes
<productname>PostgreSQL</> to report an error, aborting the current
! transaction. Setting <varname>ZERO_DAMAGED_PAGES</> to true causes
the system to instead report a warning, zero out the damaged page,
and continue processing. This behavior <emphasis>will destroy data</>,
namely all the rows on the damaged page. But it allows you to get
--- 2613,2624 ----
</varlistentry>
<varlistentry>
! <term><varname>zero_damaged_pages</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Detection of a damaged page header normally causes
<productname>PostgreSQL</> to report an error, aborting the current
! transaction. Setting <varname>zero_damaged_pages</> to true causes
the system to instead report a warning, zero out the damaged page,
and continue processing. This behavior <emphasis>will destroy data</>,
namely all the rows on the damaged page. But it allows you to get
***************
*** 2814,2820 ****
<row>
<entry><varname>SHMMAX</></>
<entry>Maximum size of shared memory segment (bytes)</>
! <entry>250 kB + 8.2 kB * <varname>SHARED_BUFFERS</> + 14.2 kB * <varname>MAX_CONNECTIONS</> up to infinity</entry>
</row>
<row>
--- 2814,2820 ----
<row>
<entry><varname>SHMMAX</></>
<entry>Maximum size of shared memory segment (bytes)</>
! <entry>250 kB + 8.2 kB * <varname>shared_buffers</> + 14.2 kB * <varname>max_connections</> up to infinity</entry>
</row>
<row>
***************
*** 3359,3365 ****
processes do so then the system-wide limit can easily be exceeded.
If you find this happening, and you do not want to alter the system-wide
limit, you can set <productname>PostgreSQL</productname>'s
! <varname>MAX_FILES_PER_PROCESS</varname> configuration parameter to
limit the consumption of open files.
</para>
</sect2>
--- 3359,3365 ----
processes do so then the system-wide limit can easily be exceeded.
If you find this happening, and you do not want to alter the system-wide
limit, you can set <productname>PostgreSQL</productname>'s
! <varname>max_files_per_process</varname> configuration parameter to
limit the consumption of open files.
</para>
</sect2>
***************
*** 3468,3474 ****
With <acronym>SSL</> support compiled in, the
<productname>PostgreSQL</> server can be started with
<acronym>SSL</> enabled by setting the parameter
! <varname>SSL</varname> to on in <filename>postgresql.conf</>. When
starting in <acronym>SSL</> mode, the server will look for the
files <filename>server.key</> and <filename>server.crt</> in the
data directory, which should contain the server private key
--- 3468,3474 ----
With <acronym>SSL</> support compiled in, the
<productname>PostgreSQL</> server can be started with
<acronym>SSL</> enabled by setting the parameter
! <varname>ssl</varname> to on in <filename>postgresql.conf</>. When
starting in <acronym>SSL</> mode, the server will look for the
files <filename>server.key</> and <filename>server.crt</> in the
data directory, which should contain the server private key
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.343
diff -c -c -r1.343 postmaster.c
*** src/backend/postmaster/postmaster.c 4 Sep 2003 03:38:55 -0000 1.343
--- src/backend/postmaster/postmaster.c 11 Sep 2003 18:23:16 -0000
***************
*** 2609,2615 ****
ereport(LOG,
(errmsg("checkpoints are occurring too frequently (%d seconds apart)",
elapsed_secs),
! errhint("Consider increasing CHECKPOINT_SEGMENTS.")));
}
LastSignalledCheckpoint = now;
}
--- 2609,2615 ----
ereport(LOG,
(errmsg("checkpoints are occurring too frequently (%d seconds apart)",
elapsed_secs),
! errhint("Consider increasing 'checkpoint_segments'.")));
}
LastSignalledCheckpoint = now;
}
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.156
diff -c -c -r1.156 guc.c
*** src/backend/utils/misc/guc.c 7 Sep 2003 15:26:53 -0000 1.156
--- src/backend/utils/misc/guc.c 11 Sep 2003 18:23:21 -0000
***************
*** 1311,1317 ****
{
{"log_error_verbosity", PGC_SUSET, LOGGING_WHEN,
gettext_noop("Controls verbosity of logged messages"),
! gettext_noop("Valid values are TERSE, DEFAULT, and VERBOSE")
},
&log_error_verbosity_str,
"default", assign_log_error_verbosity, NULL
--- 1311,1317 ----
{
{"log_error_verbosity", PGC_SUSET, LOGGING_WHEN,
gettext_noop("Controls verbosity of logged messages"),
! gettext_noop("Valid values are 'terse', 'default', and 'verbose'")
},
&log_error_verbosity_str,
"default", assign_log_error_verbosity, NULL
Attachments:
[text/plain] /bjm/diff (80.2K, 2-%2Fbjm%2Fdiff)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2003-09-11 18:29 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-09-05 00:21 minor documentation improvements Neil Conway <[email protected]>
2003-09-05 20:39 ` Peter Eisentraut <[email protected]>
2003-09-05 20:58 ` Bruce Momjian <[email protected]>
2003-09-05 21:16 ` Peter Eisentraut <[email protected]>
2003-09-05 21:18 ` Bruce Momjian <[email protected]>
2003-09-05 23:24 ` Neil Conway <[email protected]>
2003-09-06 11:29 ` Peter Eisentraut <[email protected]>
2003-09-10 20:05 ` Bruce Momjian <[email protected]>
2003-09-05 23:35 ` Tom Lane <[email protected]>
2003-09-05 23:29 ` Tom Lane <[email protected]>
2003-09-11 17:31 ` Bruce Momjian <[email protected]>
2003-09-11 18:29 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox