From 60cfe25e68db3eca3e71723803fb661db51afdb5 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 19 Jul 2006 17:02:59 +0000
Subject: Adjust spawn_process() to avoid unnecessary overhead processes: we
 can just exec instead of creating a subprocess.  This reduces process usage
 from four processes per parallel test to two.  I have no idea whether a
 comparable optimization is possible or useful in the Windows port.

---
 doc/src/sgml/regress.sgml | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index 141eaaa0bf1..fbfed9220b3 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.53 2006/07/19 02:37:00 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.54 2006/07/19 17:02:59 tgl Exp $ -->
 
  <chapter id="regress">
   <title id="regress-title">Regression Tests</title>
@@ -96,11 +96,10 @@ gmake check
    <para>
     The parallel regression test starts quite a few processes under your
     user ID.  Presently, the maximum concurrency is twenty parallel test
-    scripts, which means sixty processes: there's a server process, a
-    <application>psql</>, and usually a shell parent process for the
-    <application>psql</> for each test script.
+    scripts, which means forty processes: there's a server process and a
+    <application>psql</> process for each test script.
     So if your system enforces a per-user limit on the number of processes,
-    make sure this limit is at least seventy-five or so, else you may get
+    make sure this limit is at least fifty or so, else you may get
     random-seeming failures in the parallel test.  If you are not in
     a position to raise the limit, you can cut down the degree of parallelism
     by setting the <literal>MAX_CONNECTIONS</> parameter.  For example,
-- 
cgit v1.2.3