mirror of https://github.com/postgres/postgres
Remove SGML marked sections
For XML compatibility, replace marked sections <![IGNORE[ ]]> with comments <!-- -->. In some cases it seemed better to remove the ignored text altogether, and in one case the text should not have been ignored.
This commit is contained in:
Peter Eisentraut
parent
20b6552242
commit
22d9764646
|
|
@ -71,7 +71,7 @@ override SPFLAGS += -wall -wno-unused-param -wno-empty -wfully-tagged
|
|||
# to detect whether we are using OpenSP rather than the ancient
|
||||
# original SP.
|
||||
ifneq (,$(filter o%,$(notdir $(OSX))))
|
||||
override SPFLAGS += -wdata-delim
|
||||
override SPFLAGS += -wdata-delim -winstance-ignore-ms -winstance-include-ms -winstance-param-entity
|
||||
endif
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5275,8 +5275,6 @@ while (1)
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<![IGNORE[
|
||||
<!-- disabled by #if 0 in ecpglib -->
|
||||
<varlistentry>
|
||||
<term>-216 (<symbol>ECPG_ARRAY_INSERT</symbol>)</term>
|
||||
<listitem>
|
||||
|
|
@ -5286,7 +5284,6 @@ while (1)
|
|||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
]]>
|
||||
|
||||
<varlistentry>
|
||||
<term>-220 (<symbol>ECPG_NO_CONN</symbol>)</term>
|
||||
|
|
@ -5441,8 +5438,8 @@ while (1)
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<![IGNORE[
|
||||
<!-- currently not used by the code -->
|
||||
<!--
|
||||
<varlistentry>
|
||||
<term>-600 (<symbol>ECPG_WARNING_UNRECOGNIZED</symbol>)</term>
|
||||
<listitem>
|
||||
|
|
@ -5461,7 +5458,7 @@ while (1)
|
|||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
]]>
|
||||
-->
|
||||
|
||||
<varlistentry>
|
||||
<term>-602 (<symbol>ECPG_WARNING_UNKNOWN_PORTAL</symbol>)</term>
|
||||
|
|
|
|||
|
|
@ -8663,15 +8663,6 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
|
|||
<entry>convert path to closed</entry>
|
||||
<entry><literal>pclose(path '[(0,0),(1,1),(2,0)]')</literal></entry>
|
||||
</row>
|
||||
<![IGNORE[
|
||||
<!-- Not defined by this name. Implements the intersection operator '#' -->
|
||||
<row>
|
||||
<entry><literal><function>point(<type>lseg</>, <type>lseg</>)</function></literal></entry>
|
||||
<entry><type>point</type></entry>
|
||||
<entry>intersection</entry>
|
||||
<entry><literal>point(lseg '((-1,0),(1,0))',lseg '((-2,-2),(2,2))')</literal></entry>
|
||||
</row>
|
||||
]]>
|
||||
<row>
|
||||
<entry><literal><function>popen(<type>path</>)</function></literal></entry>
|
||||
<entry><type>path</type></entry>
|
||||
|
|
|
|||
|
|
@ -6555,103 +6555,3 @@ The following bugs have been fixed in postgres95-beta-0.02:
|
|||
Initial release.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<![IGNORE[
|
||||
<sect1 id="timing-results">
|
||||
<title>Timing Results</title>
|
||||
|
||||
<para>
|
||||
These timing results are from running the regression test with the commands
|
||||
|
||||
<programlisting>
|
||||
% cd src/test/regress
|
||||
% make all
|
||||
% time make runtest
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Timing under Linux 2.0.27 seems to have a roughly 5% variation from run
|
||||
to run, presumably due to the scheduling vagaries of multitasking systems.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Version 6.5</title>
|
||||
|
||||
<para>
|
||||
As has been the case for previous releases, timing between
|
||||
releases is not directly comparable since new regression tests
|
||||
have been added. In general, 6.5 is faster than previous
|
||||
releases.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Timing with <function>fsync()</function> disabled:
|
||||
|
||||
<literallayout class="monospaced">
|
||||
Time System
|
||||
02:00 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486
|
||||
04:38 Sparc Ultra 1 143MHz, 64MB, Solaris 2.6
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Timing with <function>fsync()</function> enabled:
|
||||
|
||||
<literallayout class="monospaced">
|
||||
Time System
|
||||
04:21 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486
|
||||
</literallayout>
|
||||
|
||||
For the <systemitem class="osname">Linux</systemitem> system above, using <acronym>UW-SCSI</acronym> disks rather than (older) <acronym>IDE</acronym>
|
||||
disks leads to a 50% improvement in speed on the regression test.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Version 6.4beta</title>
|
||||
|
||||
<para>
|
||||
The times for this release are not directly comparable to those for previous releases
|
||||
since some additional regression tests have been included.
|
||||
In general, however, 6.4 should be slightly faster than the previous release (thanks, Bruce!).
|
||||
</para>
|
||||
<para>
|
||||
<literallayout class="monospaced">
|
||||
Time System
|
||||
02:26 Dual Pentium Pro 180, 96MB, UW-SCSI, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486
|
||||
</literallayout>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Version 6.3</title>
|
||||
|
||||
<para>
|
||||
The times for this release are not directly comparable to those for previous releases
|
||||
since some additional regression tests have been included and some obsolete tests involving
|
||||
time travel have been removed.
|
||||
In general, however, 6.3 is substantially faster than previous releases (thanks, Bruce!).
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
Time System
|
||||
02:30 Dual Pentium Pro 180, 96MB, UW-SCSI, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486
|
||||
04:12 Dual Pentium Pro 180, 96MB, EIDE, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Version 6.1</title>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
Time System
|
||||
06:12 Pentium Pro 180, 32MB, EIDE, Linux 2.0.30, gcc 2.7.2 -O2 -m486
|
||||
12:06 P-100, 48MB, Linux 2.0.29, gcc
|
||||
39:58 Sparc IPC 32MB, Solaris 2.5, gcc 2.7.2.1 -O -g
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
]]>
|
||||
|
|
|
|||
|
|
@ -2434,8 +2434,8 @@ Nestloop
|
|||
in a command.
|
||||
</para>
|
||||
|
||||
<![IGNORE[
|
||||
<!-- What's happening with this? If it doesn't come back, remove this section. -->
|
||||
<!--
|
||||
<para>
|
||||
Another situation is cases on <command>UPDATE</command> where it depends on the
|
||||
change of an attribute if an action should be performed or
|
||||
|
|
@ -2456,7 +2456,7 @@ Nestloop
|
|||
if the attribute isn't touched. So the rule, qualified or not,
|
||||
will only do its scans if there ever could be something to do.
|
||||
</para>
|
||||
]]>
|
||||
-->
|
||||
|
||||
<para>
|
||||
The summary is, rules will only be significantly slower than
|
||||
|
|
|
|||
Loading…
Reference in New Issue