You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by sc...@apache.org on 2007/03/30 17:14:53 UTC
svn commit: r524117 [1/3] - /db/derby/docs/trunk/src/tuning/
Author: scotsmatrix
Date: Fri Mar 30 08:14:48 2007
New Revision: 524117
URL: http://svn.apache.org/viewvc?view=rev&rev=524117
Log:
DERBY-1590: updated the conrefs in the tuning guide to use the global conrefs file. Patch derby-1590-tuning.diff was contributed by Kim Haase.
Modified:
db/derby/docs/trunk/src/tuning/ctundepth1002853.dita
db/derby/docs/trunk/src/tuning/ctundepth1003116.dita
db/derby/docs/trunk/src/tuning/ctundepth1003209.dita
db/derby/docs/trunk/src/tuning/ctundepth1003369.dita
db/derby/docs/trunk/src/tuning/ctundepth1003672.dita
db/derby/docs/trunk/src/tuning/ctundepth10525.dita
db/derby/docs/trunk/src/tuning/ctundepth13055.dita
db/derby/docs/trunk/src/tuning/ctundepth14326.dita
db/derby/docs/trunk/src/tuning/ctundepth21935.dita
db/derby/docs/trunk/src/tuning/ctundepth23033.dita
db/derby/docs/trunk/src/tuning/ctundepth26674.dita
db/derby/docs/trunk/src/tuning/ctundepth29804.dita
db/derby/docs/trunk/src/tuning/ctundepth32379.dita
db/derby/docs/trunk/src/tuning/ctundepth36205.dita
db/derby/docs/trunk/src/tuning/ctundepth853095.dita
db/derby/docs/trunk/src/tuning/ctundepth853133.dita
db/derby/docs/trunk/src/tuning/ctunoptimz1004373.dita
db/derby/docs/trunk/src/tuning/ctunoptimz1011736.dita
db/derby/docs/trunk/src/tuning/ctunoptimz11775.dita
db/derby/docs/trunk/src/tuning/ctunoptimz11941.dita
db/derby/docs/trunk/src/tuning/ctunoptimz12168.dita
db/derby/docs/trunk/src/tuning/ctunoptimz19357.dita
db/derby/docs/trunk/src/tuning/ctunoptimz20327.dita
db/derby/docs/trunk/src/tuning/ctunoptimz22111.dita
db/derby/docs/trunk/src/tuning/ctunoptimz22460.dita
db/derby/docs/trunk/src/tuning/ctunoptimz22900.dita
db/derby/docs/trunk/src/tuning/ctunoptimz23173.dita
db/derby/docs/trunk/src/tuning/ctunoptimz23977.dita
db/derby/docs/trunk/src/tuning/ctunoptimz27036.dita
db/derby/docs/trunk/src/tuning/ctunoptimz27975.dita
db/derby/docs/trunk/src/tuning/ctunoptimz29384.dita
db/derby/docs/trunk/src/tuning/ctunoptimz30217.dita
db/derby/docs/trunk/src/tuning/ctunoptimz30768.dita
db/derby/docs/trunk/src/tuning/ctunoptimz32767.dita
db/derby/docs/trunk/src/tuning/ctunoptimz39106.dita
db/derby/docs/trunk/src/tuning/ctunoptimz41314.dita
db/derby/docs/trunk/src/tuning/ctunoptimz42065.dita
db/derby/docs/trunk/src/tuning/ctunoptimz56859.dita
db/derby/docs/trunk/src/tuning/ctunoptimz856914.dita
db/derby/docs/trunk/src/tuning/ctunoptimz857385.dita
db/derby/docs/trunk/src/tuning/ctunperf1004182.dita
db/derby/docs/trunk/src/tuning/ctunperf10679.dita
db/derby/docs/trunk/src/tuning/ctunperf16556.dita
db/derby/docs/trunk/src/tuning/ctunperf16800.dita
db/derby/docs/trunk/src/tuning/ctunperf17936.dita
db/derby/docs/trunk/src/tuning/ctunperf18705.dita
db/derby/docs/trunk/src/tuning/ctunperf22457.dita
db/derby/docs/trunk/src/tuning/ctunperf25864.dita
db/derby/docs/trunk/src/tuning/ctunperf54492.dita
db/derby/docs/trunk/src/tuning/ctunperf816059.dita
db/derby/docs/trunk/src/tuning/ctunperf816635.dita
db/derby/docs/trunk/src/tuning/ctunproper22250.dita
db/derby/docs/trunk/src/tuning/ctunproper51399.dita
db/derby/docs/trunk/src/tuning/ctunpropref1002477.dita
db/derby/docs/trunk/src/tuning/ctunpropref11181.dita
db/derby/docs/trunk/src/tuning/ctunpropref22460.dita
db/derby/docs/trunk/src/tuning/ctunpropref23947.dita
db/derby/docs/trunk/src/tuning/ctunsetprop1003847.dita
db/derby/docs/trunk/src/tuning/ctunsetprop11108.dita
db/derby/docs/trunk/src/tuning/ctunsetprop11561.dita
db/derby/docs/trunk/src/tuning/ctunsetprop12821.dita
db/derby/docs/trunk/src/tuning/ctunsetprop13074.dita
db/derby/docs/trunk/src/tuning/ctunsetprop32443.dita
db/derby/docs/trunk/src/tuning/ctunsetprop38343.dita
db/derby/docs/trunk/src/tuning/ctunsetprop44147.dita
db/derby/docs/trunk/src/tuning/ctunsetprop824451.dita
db/derby/docs/trunk/src/tuning/ctunsetprop824615.dita
db/derby/docs/trunk/src/tuning/ctunstats18908.dita
db/derby/docs/trunk/src/tuning/ctunstats52657.dita
db/derby/docs/trunk/src/tuning/ctunstats57373.dita
db/derby/docs/trunk/src/tuning/ctunstats72938.dita
db/derby/docs/trunk/src/tuning/ctunstats848901.dita
db/derby/docs/trunk/src/tuning/ctunstats849203.dita
db/derby/docs/trunk/src/tuning/ctunstats849251.dita
db/derby/docs/trunk/src/tuning/ctuntransform11313.dita
db/derby/docs/trunk/src/tuning/ctuntransform13699.dita
db/derby/docs/trunk/src/tuning/ctuntransform13966.dita
db/derby/docs/trunk/src/tuning/ctuntransform14044.dita
db/derby/docs/trunk/src/tuning/ctuntransform16033.dita
db/derby/docs/trunk/src/tuning/ctuntransform16279.dita
db/derby/docs/trunk/src/tuning/ctuntransform21780.dita
db/derby/docs/trunk/src/tuning/ctuntransform22576.dita
db/derby/docs/trunk/src/tuning/ctuntransform25857.dita
db/derby/docs/trunk/src/tuning/ctuntransform25868.dita
db/derby/docs/trunk/src/tuning/ctuntransform35783.dita
db/derby/docs/trunk/src/tuning/ctuntransform36368.dita
db/derby/docs/trunk/src/tuning/ctuntransform36623.dita
db/derby/docs/trunk/src/tuning/ctuntransform37032.dita
db/derby/docs/trunk/src/tuning/ctuntransform47182.dita
db/derby/docs/trunk/src/tuning/ctuntransform55045.dita
db/derby/docs/trunk/src/tuning/rtunoptimz1004602.dita
db/derby/docs/trunk/src/tuning/rtunoptimz1004810.dita
db/derby/docs/trunk/src/tuning/rtunproper10607.dita
db/derby/docs/trunk/src/tuning/rtunproper13217.dita
db/derby/docs/trunk/src/tuning/rtunproper13766.dita
db/derby/docs/trunk/src/tuning/rtunproper18151.dita
db/derby/docs/trunk/src/tuning/rtunproper23835.dita
db/derby/docs/trunk/src/tuning/rtunproper24390.dita
db/derby/docs/trunk/src/tuning/rtunproper24846.dita
db/derby/docs/trunk/src/tuning/rtunproper25025.dita
db/derby/docs/trunk/src/tuning/rtunproper25581.dita
db/derby/docs/trunk/src/tuning/rtunproper26978.dita
db/derby/docs/trunk/src/tuning/rtunproper26985.dita
db/derby/docs/trunk/src/tuning/rtunproper27355.dita
db/derby/docs/trunk/src/tuning/rtunproper27467.dita
db/derby/docs/trunk/src/tuning/rtunproper27529.dita
db/derby/docs/trunk/src/tuning/rtunproper28026.dita
db/derby/docs/trunk/src/tuning/rtunproper32066.dita
db/derby/docs/trunk/src/tuning/rtunproper33027.dita
db/derby/docs/trunk/src/tuning/rtunproper34037.dita
db/derby/docs/trunk/src/tuning/rtunproper35028.dita
db/derby/docs/trunk/src/tuning/rtunproper37341.dita
db/derby/docs/trunk/src/tuning/rtunproper40346.dita
db/derby/docs/trunk/src/tuning/rtunproper40688.dita
db/derby/docs/trunk/src/tuning/rtunproper43414.dita
db/derby/docs/trunk/src/tuning/rtunproper43517.dita
db/derby/docs/trunk/src/tuning/rtunproper46141.dita
db/derby/docs/trunk/src/tuning/rtunproper81359.dita
db/derby/docs/trunk/src/tuning/rtunproper81405.dita
db/derby/docs/trunk/src/tuning/rtunpropercachedn.dita
db/derby/docs/trunk/src/tuning/rtunproperdurability.dita
db/derby/docs/trunk/src/tuning/rtunpropersqlauth.dita
db/derby/docs/trunk/src/tuning/rtunsearchauthdn.dita
db/derby/docs/trunk/src/tuning/rtunsearchauthpw.dita
db/derby/docs/trunk/src/tuning/rtunstorminrecsize.dita
db/derby/docs/trunk/src/tuning/rtuntrademderby.dita
db/derby/docs/trunk/src/tuning/rtuntransform582.dita
db/derby/docs/trunk/src/tuning/rtuntransform590.dita
db/derby/docs/trunk/src/tuning/rtuntransform866547.dita
db/derby/docs/trunk/src/tuning/rtuntransform866587.dita
db/derby/docs/trunk/src/tuning/rtuntransform867602.dita
db/derby/docs/trunk/src/tuning/ttundepth33391.dita
db/derby/docs/trunk/src/tuning/ttundepth34375.dita
Modified: db/derby/docs/trunk/src/tuning/ctundepth1002853.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth1002853.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth1002853.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth1002853.dita Fri Mar 30 08:14:48 2007
@@ -26,13 +26,13 @@
</keywords>
</metadata></prolog>
<conbody>
-<p>Without a WHERE clause, <ph conref="tunconrefs.dita#prod/productshortname"></ph> is <i>supposed</i> to
+<p>Without a WHERE clause, <ph conref="../conrefs.dita#prod/productshortname"></ph> is <i>supposed</i> to
return all the data in the table, and so a table scan is the correct (if not
desirable) behavior. (More about that in <xref href="ctundepth36205.dita#ctundepth36205"></xref>.)</p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> creates indexes
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> creates indexes
on tables in the following situations: <ul>
<li>When you define a primary key, unique, or foreign key constraint on a
-table. See "CONSTRAINT clause" in the <cite><ph conref="tunconrefs.dita#pub/citref"></ph></cite> for
+table. See "CONSTRAINT clause" in the <cite><ph conref="../conrefs.dita#pub/citref"></ph></cite> for
more information.</li>
<li>When you explicitly create an index on a table with a CREATE INDEX statement. </li>
</ul></p>
@@ -41,12 +41,12 @@
<note>For a complete discussion of how indexes work and when they are useful,
see <xref href="ctunoptimz33368.dita#ctunoptimz33368"></xref> and <xref href="ctunoptimz30217.dita#ctunoptimz30217"></xref>.</note></p>
<p>Indexes provide some other benefits as well: <ul>
-<li>If all the data requested are in the index, <ph conref="tunconrefs.dita#prod/productshortname"></ph> does
+<li>If all the data requested are in the index, <ph conref="../conrefs.dita#prod/productshortname"></ph> does
not have to go to the table at all. (See <xref href="ctunoptimz30768.dita#ctunoptimz30768"></xref>.)</li>
-<li>For operations that require a sort (ORDER BY), if <ph conref="tunconrefs.dita#prod/productshortname"></ph> uses
+<li>For operations that require a sort (ORDER BY), if <ph conref="../conrefs.dita#prod/productshortname"></ph> uses
the index to retrieve the data, it does not have to perform a separate sorting
step for some of these operations in some situations. (See <xref href="ctunoptimz27036.dita#ctunoptimz27036"></xref>.)</li>
-</ul> <note><ph conref="tunconrefs.dita#prod/productshortname"></ph> does
+</ul> <note><ph conref="../conrefs.dita#prod/productshortname"></ph> does
not support indexing on columns with data types like BLOB, CLOB, and XML.</note></p>
</conbody>
</concept>
Modified: db/derby/docs/trunk/src/tuning/ctundepth1003116.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth1003116.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth1003116.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth1003116.dita Fri Mar 30 08:14:48 2007
@@ -25,8 +25,8 @@
</metadata>
</prolog>
<conbody>
-<p>If an index is useful for a query, <ph conref="tunconrefs.dita#prod/productshortname"></ph> is probably using it. However,
-you need to make sure. Analyze the way <ph conref="tunconrefs.dita#prod/productshortname"></ph> is executing your application's
+<p>If an index is useful for a query, <ph conref="../conrefs.dita#prod/productshortname"></ph> is probably using it. However,
+you need to make sure. Analyze the way <ph conref="../conrefs.dita#prod/productshortname"></ph> is executing your application's
queries. See <xref href="ttundepth33391.dita#ttundepth33391"/> for information on
how to do this.</p>
<p>In addition, over time, index pages fragment. Rebuilding indexes improves
Modified: db/derby/docs/trunk/src/tuning/ctundepth1003209.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth1003209.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth1003209.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth1003209.dita Fri Mar 30 08:14:48 2007
@@ -26,7 +26,7 @@
</metadata>
</prolog>
<conbody>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> allows you to create index columns in descending order in addition
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> allows you to create index columns in descending order in addition
to creating them in ascending order, the default. Descending indexes provide
performance benefits for the following kinds of queries that require sorting data in descending order.</p>
<p>To ensure performance benefits, verify that the descending index is being
Modified: db/derby/docs/trunk/src/tuning/ctundepth1003369.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth1003369.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth1003369.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth1003369.dita Fri Mar 30 08:14:48 2007
@@ -34,18 +34,18 @@
and ht.bed_type = 'KING'
and ht.smoking_room = 'NO'
order by ha.stay_date</b></codeblock></p>
-<p>If <ph conref="tunconrefs.dita#prod/productshortname"></ph> chooses <i>Hotels</i> as the outer table,
+<p>If <ph conref="../conrefs.dita#prod/productshortname"></ph> chooses <i>Hotels</i> as the outer table,
it can use the index on <i>Hotels</i> to retrieve qualifying
rows. Then it
need only look up data in <i>HotelAvailability</i> three
times, once for each qualifying row. And to retrieve the appropriate rows
from <i>HotelAvailability</i>, it can use an index for <i>HotelAvailability</i>'s <i>hotel_id</i> column
instead of scanning the entire table.</p>
-<p>If <ph conref="tunconrefs.dita#prod/productshortname"></ph> chooses the other order, with <i>HotelAvailability</i> as the outer table, it will have to probe the <i>Hotels</i> table for <i>every row</i>, not just three rows, because
+<p>If <ph conref="../conrefs.dita#prod/productshortname"></ph> chooses the other order, with <i>HotelAvailability</i> as the outer table, it will have to probe the <i>Hotels</i> table for <i>every row</i>, not just three rows, because
there are no qualifications on the <i>HotelAvailability</i> table.</p>
<p>For more information about join order, see <xref href="ctunoptimz12168.dita#ctunoptimz12168"/>.</p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> usually chooses a good join order. However, as with index use,
-you should make sure. Analyze the way <ph conref="tunconrefs.dita#prod/productshortname"></ph> is executing your application's
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> usually chooses a good join order. However, as with index use,
+you should make sure. Analyze the way <ph conref="../conrefs.dita#prod/productshortname"></ph> is executing your application's
queries. See <xref href="ttundepth33391.dita#ttundepth33391"/> for information on
how to do this.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctundepth1003672.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth1003672.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth1003672.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth1003672.dita Fri Mar 30 08:14:48 2007
@@ -26,7 +26,7 @@
</metadata>
</prolog>
<conbody>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> allows you to create an index that uses the descending order
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> allows you to create an index that uses the descending order
for a column. Such indexes improve the performance of queries that order results
in descending order or that search for the minimum or maximum value of an
indexed column. For example, both of the following queries could benefit from
Modified: db/derby/docs/trunk/src/tuning/ctundepth10525.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth10525.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth10525.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth10525.dita Fri Mar 30 08:14:48 2007
@@ -21,8 +21,8 @@
<prolog>
</prolog>
<conbody>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> is fast and efficient, but when tables are huge, scanning tables
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> is fast and efficient, but when tables are huge, scanning tables
might take longer than a user would expect. It's even worse if you then
-ask <ph conref="tunconrefs.dita#prod/productshortname"></ph> to sort this data.</p>
+ask <ph conref="../conrefs.dita#prod/productshortname"></ph> to sort this data.</p>
<p>Things that you can do to avoid table scans fall into two categories.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctundepth13055.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth13055.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth13055.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth13055.dita Fri Mar 30 08:14:48 2007
@@ -25,7 +25,7 @@
</metadata>
</prolog>
<conbody>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> provides a language-level tool for evaluating the performance
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> provides a language-level tool for evaluating the performance
and the execution plans of statements, the RUNTIMESTATISTICS attribute.
</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctundepth14326.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth14326.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth14326.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth14326.dita Fri Mar 30 08:14:48 2007
@@ -26,14 +26,14 @@
<conbody>
<p>JVMs tend to load classes as they are needed, which means the first time
you need a class in a piece of software, it takes longer to use.</p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> has three clear
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> has three clear
cases when a lot of class loading occurs: <ul>
<li><i>When the system boots</i> <p>The system boots when you load the embedded
driver, <i>org.apache.derby.</i><i>jdbc.EmbeddedDriver</i>. In a server framework,
-the system boots when you start the server framework. Booting <ph conref="tunconrefs.dita#prod/productshortname"></ph> loads
-basic <ph conref="tunconrefs.dita#prod/productshortname"></ph> classes.</p></li>
+the system boots when you start the server framework. Booting <ph conref="../conrefs.dita#prod/productshortname"></ph> loads
+basic <ph conref="../conrefs.dita#prod/productshortname"></ph> classes.</p></li>
<li><i>When the first database boots</i> <p>Booting the first database loads
-some more <ph conref="tunconrefs.dita#prod/productshortname"></ph> classes.
+some more <ph conref="../conrefs.dita#prod/productshortname"></ph> classes.
The default behavior is that the first database boots when the first connection
is made to it. You can also configure the system to boot databases at startup.
Depending on your application, one or the other might be preferable. </p></li>
@@ -64,7 +64,7 @@
<tbody>
<row>
<entry colname="1"> <p><b>Tuning tips for single-user systems</b> <ul>
-<li><ph conref="tunconrefs.dita#prod/productshortname"></ph> boots when you
+<li><ph conref="../conrefs.dita#prod/productshortname"></ph> boots when you
first load the embedded JDBC driver (<i>org.apache.derby.</i><i>jdbc.EmbeddedDriver</i>).
Load this driver during the least time-sensitive portion of your program,
such as when it is booting or when you are waiting for user input. For server
Modified: db/derby/docs/trunk/src/tuning/ctundepth21935.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth21935.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth21935.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth21935.dita Fri Mar 30 08:14:48 2007
@@ -27,7 +27,7 @@
</metadata>
</prolog>
<conbody>
-<p>Things that you can do to improve the performance of <ph conref="tunconrefs.dita#prod/productshortname"></ph> applications
+<p>Things that you can do to improve the performance of <ph conref="../conrefs.dita#prod/productshortname"></ph> applications
fall into three categories.
</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctundepth23033.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth23033.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth23033.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth23033.dita Fri Mar 30 08:14:48 2007
@@ -29,7 +29,7 @@
the phone book of a major metropolitan city if the book were not indexed by
name? For example, to look up the phone number for John Jones, you could not
go straight to the <i>J</i> page. You would have to read
-the entire book. That is what a table scan is like. <ph conref="tunconrefs.dita#prod/productshortname"></ph> has to read
+the entire book. That is what a table scan is like. <ph conref="../conrefs.dita#prod/productshortname"></ph> has to read
the entire table to retrieve what you are looking for unless you create useful
indexes on your table.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctundepth26674.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth26674.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth26674.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth26674.dita Fri Mar 30 08:14:48 2007
@@ -25,7 +25,7 @@
</metadata>
</prolog>
<conbody>
-<p>When RUNTIMESTATISTICS is turned on for a connection, <ph conref="tunconrefs.dita#prod/productshortname"></ph> maintains
+<p>When RUNTIMESTATISTICS is turned on for a connection, <ph conref="../conrefs.dita#prod/productshortname"></ph> maintains
information about the execution plan for each statement executed within the
connection (except for COMMIT) until the attribute is turned off.</p>
<p>For the most recently executed query, RUNTIMESTATISTICS returns information
Modified: db/derby/docs/trunk/src/tuning/ctundepth29804.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth29804.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth29804.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth29804.dita Fri Mar 30 08:14:48 2007
@@ -25,15 +25,15 @@
</metadata>
</prolog>
<conbody>
-<p>When you submit an SQL statement to <ph conref="tunconrefs.dita#prod/productshortname"></ph>, <ph conref="tunconrefs.dita#prod/productshortname"></ph> compiles
+<p>When you submit an SQL statement to <ph conref="../conrefs.dita#prod/productshortname"></ph>, <ph conref="../conrefs.dita#prod/productshortname"></ph> compiles
and then executes the statement. <i>Compilation</i> is a
time-consuming process that involves several steps, including optimization,
-the stage in which <ph conref="tunconrefs.dita#prod/productshortname"></ph> makes its statement execution plan. A statement
+the stage in which <ph conref="../conrefs.dita#prod/productshortname"></ph> makes its statement execution plan. A statement
execution plan includes whether to use an index, the join order, and so on.</p>
<p>Unless there are significant changes in the amount of data in a table or
-new or deleted indexes, <ph conref="tunconrefs.dita#prod/productshortname"></ph> will probably come up with the same statement
+new or deleted indexes, <ph conref="../conrefs.dita#prod/productshortname"></ph> will probably come up with the same statement
execution plan for the same statement if you submit it more than once. This
-means that the same statements should share the same plan, and <ph conref="tunconrefs.dita#prod/productshortname"></ph> should
-not recompile them. <ph conref="tunconrefs.dita#prod/productshortname"></ph> allows you to ensure this in the following
+means that the same statements should share the same plan, and <ph conref="../conrefs.dita#prod/productshortname"></ph> should
+not recompile them. <ph conref="../conrefs.dita#prod/productshortname"></ph> allows you to ensure this in the following
ways (in order of importance): </p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctundepth32379.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth32379.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth32379.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth32379.dita Fri Mar 30 08:14:48 2007
@@ -36,9 +36,9 @@
which can contain dynamic or IN parameters. Instead of using the literals
for changing parameters, use question marks (?) as placeholders for such parameters.
Provide the values when you execute the statement.</p></li>
-</ul><ph conref="tunconrefs.dita#prod/productshortname"></ph> supports the <i>ParameterMetaData</i> interface,
+</ul><ph conref="../conrefs.dita#prod/productshortname"></ph> supports the <i>ParameterMetaData</i> interface,
new in JDBC 3.0. This interface describes the number, type, and properties
-of prepared statement parameters. See the <cite><ph conref="tunconrefs.dita#pub/citdevelop"></ph></cite> for
+of prepared statement parameters. See the <cite><ph conref="../conrefs.dita#pub/citdevelop"></ph></cite> for
more information.</p>
<p> <fig expanse="column" id="ctundepth42475"><title>A connection need only
compile a <i>PreparedStatement</i> once</title><desc>Subsequent executions
@@ -49,14 +49,14 @@
statement execution plan.</alt></image>
</fig><ul>
<li>Even if your statement uses <i>Statements</i> instead of <i>PreparedStatements</i>, <ph
-conref="tunconrefs.dita#prod/productshortname"></ph> can reuse the statement
+conref="../conrefs.dita#prod/productshortname"></ph> can reuse the statement
execution plan for the statements from the statement cache. Statements from
any connection can share the same statement execution plan, avoiding compilation,
by using the single-statement cache. The statement cache maintains statement
plans across connections. It does not, however, maintain them across reboots.
See the figure below. <p>When, in the same database, an application submits
an SQL <i>Statement</i> that exactly matches one already in the cache, <ph
-conref="tunconrefs.dita#prod/productshortname"></ph> grabs the statement from
+conref="../conrefs.dita#prod/productshortname"></ph> grabs the statement from
the cache, even if the <i>Statement</i> has already been closed by the application.</p> <p>To
match exactly with a statement already in the cache, the SQL <i>Statement</i> must
meet the following requirements:</p> <ul>
Modified: db/derby/docs/trunk/src/tuning/ctundepth36205.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth36205.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth36205.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth36205.dita Fri Mar 30 08:14:48 2007
@@ -34,7 +34,7 @@
<codeblock><b>SELECT * FROM ExtremelyHugeTable
ORDER BY unIndexedColumn</b></codeblock></p>
<p>This statement has no WHERE clause. It will require a full table scan.
-To make matters worse, <ph conref="tunconrefs.dita#prod/productshortname"></ph> will then have to order the data. Most
+To make matters worse, <ph conref="../conrefs.dita#prod/productshortname"></ph> will then have to order the data. Most
likely, the user does not want to browse through all 100,000 rows, and does
not care whether the rows are all in order.</p>
<p>Do everything you can to avoid table scans and sorting of large results
Modified: db/derby/docs/trunk/src/tuning/ctundepth853095.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth853095.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth853095.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth853095.dita Fri Mar 30 08:14:48 2007
@@ -27,7 +27,7 @@
<conbody>
<p>If you are using statistics timing, RUNTIMESTATISTICS provides information
about how long each stage of the statement took. An SQL statement has
-two basic stages within <ph conref="tunconrefs.dita#prod/productshortname"></ph>: compilation and execution. Compilation
+two basic stages within <ph conref="../conrefs.dita#prod/productshortname"></ph>: compilation and execution. Compilation
is the work done while the statement is prepared. Compilation is composed
of the following stages: parsing, binding, optimization, and code generation.
Execution is the actual evaluation of the statement.</p>
Modified: db/derby/docs/trunk/src/tuning/ctundepth853133.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth853133.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth853133.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth853133.dita Fri Mar 30 08:14:48 2007
@@ -161,10 +161,10 @@
<p>For inserts, updates, and deletes, rows flow out of the top, where they
are inserted, updated, or deleted. For selects (queries), rows flow out of
the top into a result set that is returned to the user.</p>
-<p>The <cite><ph conref="tunconrefs.dita#pub/citref"></ph></cite> shows the
+<p>The <cite><ph conref="../conrefs.dita#pub/citref"></ph></cite> shows the
many possible <i>ResultSet</i> nodes that might appear in an execution plan. </p>
<p>In addition, read <xref href="ctunoptimz39739.dita#ctunoptimz39739"></xref>,
-for more information about some of the ways in which <ph conref="tunconrefs.dita#prod/productshortname"></ph> executes statements.</p>
+for more information about some of the ways in which <ph conref="../conrefs.dita#prod/productshortname"></ph> executes statements.</p>
</conbody>
</concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz1004373.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz1004373.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz1004373.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz1004373.dita Fri Mar 30 08:14:48 2007
@@ -25,7 +25,7 @@
</metadata>
</prolog>
<conbody>
-<p>Joins specified by the JOIN keyword are optimizable. This means that <ph conref="tunconrefs.dita#prod/productshortname"></ph> can
+<p>Joins specified by the JOIN keyword are optimizable. This means that <ph conref="../conrefs.dita#prod/productshortname"></ph> can
use an index on the inner table of the join (start and stop conditions are
being supplied implicitly by the rows in the outer table).</p>
<p>Note that joins built using traditional predicates are also optimizable.
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz1011736.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz1011736.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz1011736.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz1011736.dita Fri Mar 30 08:14:48 2007
@@ -21,7 +21,7 @@
<prolog>
</prolog>
<conbody>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> can use a hash table instead of a sorter to eliminate duplicates
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can use a hash table instead of a sorter to eliminate duplicates
when performing a DISTINCT in the following cases:
<ul>
<li>There is a single table in the query block. </li>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz11775.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz11775.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz11775.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz11775.dita Fri Mar 30 08:14:48 2007
@@ -30,5 +30,5 @@
with the LOCK TABLE statement. This is useful if you know in advance that
an entire table should be locked and want to save the resources required for
obtaining row locks until the system escalates the locking. For information
-about this feature, see "LOCK TABLE statement" in the <cite><ph conref="tunconrefs.dita#pub/citref"></ph></cite>.</p>
+about this feature, see "LOCK TABLE statement" in the <cite><ph conref="../conrefs.dita#pub/citref"></ph></cite>.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz11941.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz11941.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz11941.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz11941.dita Fri Mar 30 08:14:48 2007
@@ -28,7 +28,7 @@
<p>The optimizer compares the cost of choosing a hash join (if a hash join
is possible) to the cost of choosing a nested loop join and chooses the cheaper
strategy. For information about when hash joins are possible, see <xref href="ctunoptimz23173.dita#ctunoptimz23173"/>.</p>
-<p>In some cases, the size of the hash table that <ph conref="tunconrefs.dita#prod/productshortname"></ph> would have to
+<p>In some cases, the size of the hash table that <ph conref="../conrefs.dita#prod/productshortname"></ph> would have to
build is prohibitive and can cause the JVM to run out of memory. For this
reason, the optimizer has an upper limit on the size of a table on which it
will consider a hash join. It will not consider a hash join for a statement
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz12168.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz12168.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz12168.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz12168.dita Fri Mar 30 08:14:48 2007
@@ -25,7 +25,7 @@
</metadata>
</prolog>
<conbody>
-<p>Joins, SQL statements in which <ph conref="tunconrefs.dita#prod/productshortname"></ph> selects data from two
+<p>Joins, SQL statements in which <ph conref="../conrefs.dita#prod/productshortname"></ph> selects data from two
or more tables using one or more key columns from each table, can vary widely
in performance. Factors that affect the performance of joins are join order,
indexes, and join strategy.</p>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz19357.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz19357.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz19357.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz19357.dita Fri Mar 30 08:14:48 2007
@@ -30,7 +30,7 @@
use table-level locking or row-level locking for each table in each DML statement.
The system bases this decision on the number of rows read or written for each
table, and on whether a full conglomerate scan is done for each table.
-<note>When you have turned off row-level locking for your system, <ph conref="tunconrefs.dita#prod/productshortname"></ph> always
+<note>When you have turned off row-level locking for your system, <ph conref="../conrefs.dita#prod/productshortname"></ph> always
uses table-level locking.</note></p>
<p>The first goal of the system's decision is concurrency; wherever possible,
the system chooses row-level locking. However, row-level locking uses a lot
@@ -44,10 +44,10 @@
FROM FlightAvailability AS fa, Flights AS fts
WHERE fts.flight_id = fa.flight_id
AND fts.segment_number = fa.segment_number</b></codeblock></p>
-<p>To satisfy the isolation requirements, <ph conref="tunconrefs.dita#prod/productshortname"></ph> would have to lock all
+<p>To satisfy the isolation requirements, <ph conref="../conrefs.dita#prod/productshortname"></ph> would have to lock all
the rows in both the<i> FlightAvailability</i> and the <i>Flights</i> tables. Locking both the tables would be cheaper,
would provide the same isolation, and would allow the same concurrency.
<note>You can force lock escalation for specific tables when you alter
-them with the LOCKSIZE clause. For these tables, <ph conref="tunconrefs.dita#prod/productshortname"></ph> always chooses
-table-level locking. For more information, see the <cite><ph conref="tunconrefs.dita#pub/citref"></ph></cite>.</note><indexterm>Table-level locking<indexterm>forcing for a specific table at creation time</indexterm></indexterm></p>
+them with the LOCKSIZE clause. For these tables, <ph conref="../conrefs.dita#prod/productshortname"></ph> always chooses
+table-level locking. For more information, see the <cite><ph conref="../conrefs.dita#pub/citref"></ph></cite>.</note><indexterm>Table-level locking<indexterm>forcing for a specific table at creation time</indexterm></indexterm></p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz20327.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz20327.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz20327.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz20327.dita Fri Mar 30 08:14:48 2007
@@ -43,6 +43,6 @@
<li>The number of rows and pages to be scanned for each table in each join
order</li>
</ul>
-<note><ph conref="tunconrefs.dita#prod/productshortname"></ph> does transitive closure on qualifications.
+<note><ph conref="../conrefs.dita#prod/productshortname"></ph> does transitive closure on qualifications.
For details, see <xref href="ctuntransform37032.dita#ctuntransform37032"/>.</note></p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz22111.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz22111.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz22111.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz22111.dita Fri Mar 30 08:14:48 2007
@@ -28,7 +28,7 @@
<conbody>
<p>The optimizer knows that it can avoid iterating through all the source
rows in a result to compute a MIN() or MAX() aggregate when data are already
-in the right order. When data are guaranteed to be in the right order, <ph conref="tunconrefs.dita#prod/productshortname"></ph> can
+in the right order. When data are guaranteed to be in the right order, <ph conref="../conrefs.dita#prod/productshortname"></ph> can
go immediately to the smallest (minimum) or largest (maximum) row.</p>
<p>The following conditions must be true:
<ul>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz22460.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz22460.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz22460.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz22460.dita Fri Mar 30 08:14:48 2007
@@ -21,13 +21,13 @@
<prolog>
</prolog>
<conbody>
-<p>In most cases, <ph conref="tunconrefs.dita#prod/productshortname"></ph> needs to perform two separate steps for statements
+<p>In most cases, <ph conref="../conrefs.dita#prod/productshortname"></ph> needs to perform two separate steps for statements
that use DISTINCT or GROUP BY: first sorting the selected columns, then either
discarding duplicate rows or aggregating grouped rows. Sometimes it is able
to avoid sorting for these statements with tuple filtering. <i>Tuple filtering</i> means that the rows are <i>already</i> in
-a useful order. For DISTINCT, <ph conref="tunconrefs.dita#prod/productshortname"></ph> can simply filter out duplicate
+a useful order. For DISTINCT, <ph conref="../conrefs.dita#prod/productshortname"></ph> can simply filter out duplicate
values when they are found and return results to the user sooner. For GROUP
-BY, <ph conref="tunconrefs.dita#prod/productshortname"></ph> can aggregate a group of rows until a new set of rows is detected
+BY, <ph conref="../conrefs.dita#prod/productshortname"></ph> can aggregate a group of rows until a new set of rows is detected
and return results to the user sooner.</p>
<p>These are non-cost-based optimizations; the optimizer does not yet consider
the cost of these optimizations.</p>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz22900.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz22900.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz22900.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz22900.dita Fri Mar 30 08:14:48 2007
@@ -24,7 +24,7 @@
<p>Sometimes a table scan is the most efficient way to access data, even if
a potentially useful index is available. For example, if the statement returns
virtually all the data in the table, it is more efficient to go straight to
-the table instead of looking values up in an index, because then <ph conref="tunconrefs.dita#prod/productshortname"></ph> is
+the table instead of looking values up in an index, because then <ph conref="../conrefs.dita#prod/productshortname"></ph> is
able to avoid the intermediate step of retrieving the rows from the index
lookup values.</p>
<p>For example:
@@ -33,9 +33,9 @@
WHERE dest_airport < 'Z'</b></codeblock></p>
<p>In the <i>Flights </i>table, most of the airport codes
begin with letters that are less than <i>Z</i>. Depending
-on the number of rows in the table, it is probably more efficient for <ph conref="tunconrefs.dita#prod/productshortname"></ph> to
+on the number of rows in the table, it is probably more efficient for <ph conref="../conrefs.dita#prod/productshortname"></ph> to
go straight to the table to retrieve the appropriate rows. However, for the
-following query, <ph conref="tunconrefs.dita#prod/productshortname"></ph> uses the index:
+following query, <ph conref="../conrefs.dita#prod/productshortname"></ph> uses the index:
<codeblock><b>SELECT *
FROM Flights
WHERE dest_airport < 'B'</b></codeblock></p>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz23173.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz23173.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz23173.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz23173.dita Fri Mar 30 08:14:48 2007
@@ -31,13 +31,13 @@
</metadata>
</prolog>
<conbody>
-<p>The most common join strategy in <ph conref="tunconrefs.dita#prod/productshortname"></ph> is called a <i>nested loop</i>. For each qualifying row in the outer table, <ph conref="tunconrefs.dita#prod/productshortname"></ph> uses
+<p>The most common join strategy in <ph conref="../conrefs.dita#prod/productshortname"></ph> is called a <i>nested loop</i>. For each qualifying row in the outer table, <ph conref="../conrefs.dita#prod/productshortname"></ph> uses
the appropriate access path (index or table) to find the matching rows in
the inner table.</p>
-<p>Another type of join in <ph conref="tunconrefs.dita#prod/productshortname"></ph> is called a <i>hash</i> join. For joins of this type, <ph conref="tunconrefs.dita#prod/productshortname"></ph> constructs a hash table representing
+<p>Another type of join in <ph conref="../conrefs.dita#prod/productshortname"></ph> is called a <i>hash</i> join. For joins of this type, <ph conref="../conrefs.dita#prod/productshortname"></ph> constructs a hash table representing
all the selected columns of the inner table. For each qualifying row in the
-outer table, <ph conref="tunconrefs.dita#prod/productshortname"></ph> does a quick lookup on the hash table to get the
-inner table data. <ph conref="tunconrefs.dita#prod/productshortname"></ph> has to scan the inner table or index only once,
+outer table, <ph conref="../conrefs.dita#prod/productshortname"></ph> does a quick lookup on the hash table to get the
+inner table data. <ph conref="../conrefs.dita#prod/productshortname"></ph> has to scan the inner table or index only once,
to build the hash table.</p>
<p>Nested loop joins are preferable in most situations.</p>
<p>Hash joins are preferable in situations in which the inner table values
@@ -59,5 +59,5 @@
to a high number; allowing the optimizer the maximum flexibility in considering
a join strategy queries involving large queries leads to better performance.
It can also be set to smaller values for more limited environments.
-<note><ph conref="tunconrefs.dita#prod/productshortname"></ph> allows multiple columns as hash keys.</note></p>
+<note><ph conref="../conrefs.dita#prod/productshortname"></ph> allows multiple columns as hash keys.</note></p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz23977.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz23977.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz23977.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz23977.dita Fri Mar 30 08:14:48 2007
@@ -37,11 +37,11 @@
DBMS will usually make a good choice regardless of how the query is written.
The optimizer does not necessarily make the <i>best</i> choice,
just a good one.</p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> can use indexes to improve the performance of DML (data manipulation
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can use indexes to improve the performance of DML (data manipulation
language) statements such as queries, updates, and deletes. The query optimizer
can make decisions about whether to use an index for a particular table (access
path) and also makes decisions about join order, type of join, and a few other
matters.</p>
-<p>This section gives an overview of the <ph conref="tunconrefs.dita#prod/productshortname"></ph> optimizer and discusses
+<p>This section gives an overview of the <ph conref="../conrefs.dita#prod/productshortname"></ph> optimizer and discusses
performance issues in the execution of DML statements.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz27036.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz27036.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz27036.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz27036.dita Fri Mar 30 08:14:48 2007
@@ -28,12 +28,12 @@
<p>Some SQL statements require that data be ordered, including those with
ORDER BY, GROUP BY, and DISTINCT. MIN() and MAX() aggregates also require
ordering of data.</p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> can sometimes avoid sorting steps for:
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can sometimes avoid sorting steps for:
<ul>
<li>statements with ORDER BY
<p>See <xref href="ctunoptimz56859.dita#ctunoptimz56859"/></p></li>
</ul></p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> can also perform the following optimizations, but they are
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can also perform the following optimizations, but they are
not based on cost:
<ul>
<li>sort avoidance for DISTINCT and GROUP BYs
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz27975.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz27975.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz27975.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz27975.dita Fri Mar 30 08:14:48 2007
@@ -28,7 +28,7 @@
<p>Row-level locking improves concurrency in a multi-user system. However,
a large number of row locks can degrade performance. <xref href="ctunoptimz19357.dita#ctunoptimz19357"/> discussed the way the optimizer makes some compile-time decisions
about escalating row locks to table locks for performance reasons. This section
-discusses ways in which the <ph conref="tunconrefs.dita#prod/productshortname"></ph> system and the user can make similar
+discusses ways in which the <ph conref="../conrefs.dita#prod/productshortname"></ph> system and the user can make similar
lock escalations.
</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz29384.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz29384.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz29384.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz29384.dita Fri Mar 30 08:14:48 2007
@@ -25,9 +25,9 @@
</metadata>
</prolog>
<conbody>
-<p>When <ph conref="tunconrefs.dita#prod/productshortname"></ph> retrieves data from a conglomerate, it can fetch more
+<p>When <ph conref="../conrefs.dita#prod/productshortname"></ph> retrieves data from a conglomerate, it can fetch more
than one row at a time. Fetching more than one row at a time is called bulk
-fetch. By default, <ph conref="tunconrefs.dita#prod/productshortname"></ph> fetches 16 rows at a time.</p>
+fetch. By default, <ph conref="../conrefs.dita#prod/productshortname"></ph> fetches 16 rows at a time.</p>
<p>Bulk fetch is faster than retrieving one row at a time when a large number
of rows qualify for each scan of the table or index. Bulk fetch uses extra
memory to hold the pre-fetched rows, so it should be avoided in situations
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz30217.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz30217.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz30217.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz30217.dita Fri Mar 30 08:14:48 2007
@@ -22,9 +22,9 @@
</prolog>
<conbody>
<p>If you define an index on a column or columns, the query optimizer can
-use the index to find data in the column more quickly. <ph conref="tunconrefs.dita#prod/productshortname"></ph> automatically
+use the index to find data in the column more quickly. <ph conref="../conrefs.dita#prod/productshortname"></ph> automatically
creates indexes to back up primary key, foreign key, and unique constraints,
so those indexes are always available to the optimizer, as well as those that
-you explicitly create with the CREATE INDEX command. The way <ph conref="tunconrefs.dita#prod/productshortname"></ph> gets
+you explicitly create with the CREATE INDEX command. The way <ph conref="../conrefs.dita#prod/productshortname"></ph> gets
to the data-via an index or directly via the table-is called the <i>access path</i>.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz30768.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz30768.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz30768.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz30768.dita Fri Mar 30 08:14:48 2007
@@ -30,16 +30,16 @@
query. An index <i>covers the query</i> if all the columns
specified in the query are part of the index. These are the columns that are
all columns referenced in the query, not just columns in a WHERE clause. If
-so, <ph conref="tunconrefs.dita#prod/productshortname"></ph> never has to go to the data pages at all, but can retrieve
+so, <ph conref="../conrefs.dita#prod/productshortname"></ph> never has to go to the data pages at all, but can retrieve
all data through index access alone. For example, in the following queries, <i>OrigIndex</i> covers the query:
<codeblock><b>SELECT orig_airport
FROM Flights
SELECT DISTINCT lower(orig_airport) FROM Flights
FROM Flights</b></codeblock></p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> can get all required data out of the index instead of from
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can get all required data out of the index instead of from
the table.</p>
<note>If the query produces an updatable result set,
-<ph conref="tunconrefs.dita#prod/productshortname"></ph> will retrieve all
+<ph conref="../conrefs.dita#prod/productshortname"></ph> will retrieve all
data from the data pages even if there is an index that covers the query.</note>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz32767.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz32767.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz32767.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz32767.dita Fri Mar 30 08:14:48 2007
@@ -54,6 +54,6 @@
AND fa.segment_number = fts.segment_number</b></codeblock></p>
<p>Although the difference in cost is smaller, it is still cheaper for the <i>Flights</i> table to be the inner table, because its index
is unique, whereas <i>FlightAvailability</i>'s index
-is not. That is because it is cheaper for <ph conref="tunconrefs.dita#prod/productshortname"></ph> to step through a unique
+is not. That is because it is cheaper for <ph conref="../conrefs.dita#prod/productshortname"></ph> to step through a unique
index than through a non-unique index.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz39106.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz39106.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz39106.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz39106.dita Fri Mar 30 08:14:48 2007
@@ -25,14 +25,14 @@
</metadata>
</prolog>
<conbody>
-<p>As you learned in the previous section, <ph conref="tunconrefs.dita#prod/productshortname"></ph> might be able to use
-an index on a column to find data more quickly. If <ph conref="tunconrefs.dita#prod/productshortname"></ph> can use an
-index for a statement, that statement is said to be <i>optimizable</i>. The statements shown in the preceding section allow <ph conref="tunconrefs.dita#prod/productshortname"></ph> to
+<p>As you learned in the previous section, <ph conref="../conrefs.dita#prod/productshortname"></ph> might be able to use
+an index on a column to find data more quickly. If <ph conref="../conrefs.dita#prod/productshortname"></ph> can use an
+index for a statement, that statement is said to be <i>optimizable</i>. The statements shown in the preceding section allow <ph conref="../conrefs.dita#prod/productshortname"></ph> to
use the index because their WHERE clauses provide start and stop conditions.
-That is, they tell <ph conref="tunconrefs.dita#prod/productshortname"></ph> the point at which to begin its scan of the
+That is, they tell <ph conref="../conrefs.dita#prod/productshortname"></ph> the point at which to begin its scan of the
index and where to end the scan.</p>
<p>For example, a statement with a WHERE clause looking for rows for which
-the <i>orig_airport</i> value is less than <i>BBB</i> means that <ph conref="tunconrefs.dita#prod/productshortname"></ph> must begin the scan at the beginning of the
+the <i>orig_airport</i> value is less than <i>BBB</i> means that <ph conref="../conrefs.dita#prod/productshortname"></ph> must begin the scan at the beginning of the
index; it can end the scan at <i>BBB</i>. This means that
it avoids scanning the index for most of the entries.</p>
<p>An index scan that uses start or stop conditions is called a <i>matching index scan</i>.
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz41314.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz41314.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz41314.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz41314.dita Fri Mar 30 08:14:48 2007
@@ -34,7 +34,7 @@
WHERE orig_airport < 'BBB'
AND orig_airport <> 'AKL'</b></codeblock></p>
<p>The second predicate is not optimizable, but the first predicate is. The
-second predicate becomes a qualification for which <ph conref="tunconrefs.dita#prod/productshortname"></ph> evaluates the
+second predicate becomes a qualification for which <ph conref="../conrefs.dita#prod/productshortname"></ph> evaluates the
entries in the index as it traverses it.
<ul>
<li>The following comparisons are valid qualifiers:
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz42065.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz42065.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz42065.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz42065.dita Fri Mar 30 08:14:48 2007
@@ -32,7 +32,7 @@
lot of inserts or updates, a transaction can accumulate a number of row locks
even though no single statement would touch enough rows to make the optimizer
choose table-level locking for any single table.</p>
-<p>However, during a transaction, the <ph conref="tunconrefs.dita#prod/productshortname"></ph> system tracks the number
+<p>However, during a transaction, the <ph conref="../conrefs.dita#prod/productshortname"></ph> system tracks the number
of locks for all tables in the transaction, and when this number exceeds a
threshold number (which you can configure; see <xref href="ctunoptimz26019.dita#ctunoptimz26019"/>), the system attempts to escalate locking for at least one
of the tables involved from row-level to table-level locking.</p>
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz56859.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz56859.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz56859.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz56859.dita Fri Mar 30 08:14:48 2007
@@ -28,15 +28,15 @@
<p>Usually, sorting requires an extra step to put the data into the right
order. This extra step can be avoided for data that are already in the right
order. For example, if a single-table query has an ORDER BY on a single column,
-and there is an index on that column, sorting can be avoided if <ph conref="tunconrefs.dita#prod/productshortname"></ph> uses
+and there is an index on that column, sorting can be avoided if <ph conref="../conrefs.dita#prod/productshortname"></ph> uses
the index as the access path.</p>
-<p>Where possible, <ph conref="tunconrefs.dita#prod/productshortname"></ph>'s query compiler transforms an SQL statement
+<p>Where possible, <ph conref="../conrefs.dita#prod/productshortname"></ph>'s query compiler transforms an SQL statement
internally into one that avoids this extra step. For information about internal
transformations, see <xref href="ctuntransform16033.dita#ctuntransform16033"/>. This
transformation, if it occurs, happens before optimization. After any such
transformations are made, the optimizer can do its part to help avoid a separate
sorting step by choosing an already sorted access path. It compares the cost
-of using that path with the cost of sorting. <ph conref="tunconrefs.dita#prod/productshortname"></ph> does this for statements
+of using that path with the cost of sorting. <ph conref="../conrefs.dita#prod/productshortname"></ph> does this for statements
that use an ORDER BY clause in the following situations:
<ul>
<li>The statements involve tables with indexes that are in the correct order.</li>
@@ -46,14 +46,14 @@
<p>ORDER BY specifies a priority of ordering of columns in a result set. For
example, ORDER BY X, Y means that column <i>X</i> has a more
significant ordering than column <i>Y</i>.</p>
-<p>The situations that allow <ph conref="tunconrefs.dita#prod/productshortname"></ph> to avoid a separate
+<p>The situations that allow <ph conref="../conrefs.dita#prod/productshortname"></ph> to avoid a separate
ordering step for statements with ORDER BY clauses are:
<ul>
<li>Index scans, which provide the correct order.
<codeblock><b><ph>-- covering index</ph>
SELECT flight_id FROM Flights ORDER BY flight_id</b></codeblock></li>
<li>The rows from a table when fetched through an index scan.
-<codeblock><b><ph>-- if <ph conref="tunconrefs.dita#prod/productshortname"></ph> uses the index on orig_airport
+<codeblock><b><ph>-- if <ph conref="../conrefs.dita#prod/productshortname"></ph> uses the index on orig_airport
-- to access the data, it can avoid the sort
-- required by the final ORDER BY</ph>
SELECT orig_airport, miles
@@ -62,7 +62,7 @@
ORDER BY orig_airport</b></codeblock></li>
<li>The rows from a join when ordered by the indexed column or columns in
the outer table.
-<codeblock><b><b><ph>-- if <ph conref="tunconrefs.dita#prod/productshortname"></ph> chooses Cities as the outer table, it
+<codeblock><b><b><ph>-- if <ph conref="../conrefs.dita#prod/productshortname"></ph> chooses Cities as the outer table, it
-- can avoid a separate sorting step</ph></b>
SELECT * FROM cities, countries
WHERE cities.country_ISO_code = countries.country_ISO_code
@@ -95,7 +95,7 @@
<p>And because of transitive
closure, this means that even more complex statements can avoid sorting. For
example:
-<codeblock><b><ph>-- transitive closure means that <ph conref="tunconrefs.dita#prod/productshortname"></ph> will
+<codeblock><b><ph>-- transitive closure means that <ph conref="../conrefs.dita#prod/productshortname"></ph> will
-- add this clause:
-- AND countries.country_ISO_code = 'CL', which means
-- that the ordering column is now compared to a constant,
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz856914.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz856914.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz856914.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz856914.dita Fri Mar 30 08:14:48 2007
@@ -25,7 +25,7 @@
</metadata>
</prolog>
<conbody>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> has to do work to maintain indexes. If you insert into or delete
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> has to do work to maintain indexes. If you insert into or delete
from a table, the system has to insert or delete rows in all the indexes on
the table. If you update a table, the system has to maintain those indexes
that are on the columns being updated. So having a lot of indexes can speed
Modified: db/derby/docs/trunk/src/tuning/ctunoptimz857385.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunoptimz857385.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunoptimz857385.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunoptimz857385.dita Fri Mar 30 08:14:48 2007
@@ -23,15 +23,15 @@
<conbody>
<p><indexterm>Join order<indexterm>performance implications
of</indexterm></indexterm><indexterm>Join order<indexterm>rules
-of thumb</indexterm></indexterm>The <ph conref="tunconrefs.dita#prod/productshortname"></ph> optimizer usually makes a good
+of thumb</indexterm></indexterm>The <ph conref="../conrefs.dita#prod/productshortname"></ph> optimizer usually makes a good
choice about join order. This section discusses the performance implications
of join order.</p>
-<p>In a join operation involving two tables, <ph conref="tunconrefs.dita#prod/productshortname"></ph> scans the tables
-in a particular order. <ph conref="tunconrefs.dita#prod/productshortname"></ph> accesses rows in one table first, and this
+<p>In a join operation involving two tables, <ph conref="../conrefs.dita#prod/productshortname"></ph> scans the tables
+in a particular order. <ph conref="../conrefs.dita#prod/productshortname"></ph> accesses rows in one table first, and this
table is now called the <i>outer table</i>.</p>
-<p>Then, for each qualifying row in the outer table, <ph conref="tunconrefs.dita#prod/productshortname"></ph> looks for
+<p>Then, for each qualifying row in the outer table, <ph conref="../conrefs.dita#prod/productshortname"></ph> looks for
matching rows in the second table, which is called the <i>inner table</i>.</p>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> accesses the outer table once, and the inner table probably
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> accesses the outer table once, and the inner table probably
many times (depending on how many rows in the outer table qualify).</p>
<p>This leads to a few general rules of thumb about join order:
<ul>
@@ -41,18 +41,18 @@
<ul compact="yes">
<li>If <i>only one</i> table has an index on the joined column
or columns, it is much better for that table to be the inner table. This is
-because for each of the many inner table lookups, <ph conref="tunconrefs.dita#prod/productshortname"></ph> can use an index
+because for each of the many inner table lookups, <ph conref="../conrefs.dita#prod/productshortname"></ph> can use an index
instead of scanning the entire table.</li>
<li>Since indexes on inner tables are accessed many times, if the index on
one table is smaller than the index on another, the table with the smaller
one should probably be the inner table. That is because smaller indexes (or
-tables) can be cached (kept in <ph conref="tunconrefs.dita#prod/productshortname"></ph>'s memory, allowing <ph conref="tunconrefs.dita#prod/productshortname"></ph> to
+tables) can be cached (kept in <ph conref="../conrefs.dita#prod/productshortname"></ph>'s memory, allowing <ph conref="../conrefs.dita#prod/productshortname"></ph> to
avoid expensive I/O for each iteration).</li>
</ul></li>
<li>On the other hand, if a query has restrictions in the WHERE clause for
one table that would cause it to return only a few rows from that table (for
example, WHERE flight_id = 'AA1111'), it is better for the restricted table
-to be the outer table. <ph conref="tunconrefs.dita#prod/productshortname"></ph> will have to go to the inner table only
+to be the outer table. <ph conref="../conrefs.dita#prod/productshortname"></ph> will have to go to the inner table only
a few times anyway.
<p id="ctunoptimz29721">Consider:
<codeblock><b>SELECT *
Modified: db/derby/docs/trunk/src/tuning/ctunperf1004182.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf1004182.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf1004182.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf1004182.dita Fri Mar 30 08:14:48 2007
@@ -27,8 +27,8 @@
<ul>
<li><i>Limited memory</i>
<p>Large database pages reduce
-I/O time because <ph conref="tunconrefs.dita#prod/productshortname"></ph> can access more data with fewer I/Os. However,
-large pages require more memory. <ph conref="tunconrefs.dita#prod/productshortname"></ph> allocates a bulk number of database
+I/O time because <ph conref="../conrefs.dita#prod/productshortname"></ph> can access more data with fewer I/Os. However,
+large pages require more memory. <ph conref="../conrefs.dita#prod/productshortname"></ph> allocates a bulk number of database
pages in its page cache by default. If the page size is large, the system
might run out of memory.</p>
<p>Here's a rough guideline: If the system
Modified: db/derby/docs/trunk/src/tuning/ctunperf10679.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf10679.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf10679.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf10679.dita Fri Mar 30 08:14:48 2007
@@ -26,7 +26,7 @@
</prolog>
<conbody>
<p>By creating indexes on columns by which you often search a table, you can
-reduce the number of rows that <ph conref="tunconrefs.dita#prod/productshortname"></ph> has to scan, thus improving performance.
+reduce the number of rows that <ph conref="../conrefs.dita#prod/productshortname"></ph> has to scan, thus improving performance.
Depending on the size of the table and the number of rows returned, the improvement
can be dramatic. Indexes work best when the number of rows returned from the
query is a fraction of the number of rows in the table.</p>
Modified: db/derby/docs/trunk/src/tuning/ctunperf16556.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf16556.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf16556.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf16556.dita Fri Mar 30 08:14:48 2007
@@ -27,8 +27,8 @@
</metadata>
</prolog>
<conbody>
-<p>By default, <ph conref="tunconrefs.dita#prod/productshortname"></ph> does not boot databases (and some core <ph conref="tunconrefs.dita#prod/productshortname"></ph> classes)
-in the system at <ph conref="tunconrefs.dita#prod/productshortname"></ph> startup but only at connection time. For multi-user
+<p>By default, <ph conref="../conrefs.dita#prod/productshortname"></ph> does not boot databases (and some core <ph conref="../conrefs.dita#prod/productshortname"></ph> classes)
+in the system at <ph conref="../conrefs.dita#prod/productshortname"></ph> startup but only at connection time. For multi-user
systems, you might want to reduce connection time by booting one or all databases
at startup instead.</p>
<p>For embedded systems, you might want to boot the database in a separate
Modified: db/derby/docs/trunk/src/tuning/ctunperf16800.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf16800.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf16800.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf16800.dita Fri Mar 30 08:14:48 2007
@@ -29,9 +29,9 @@
<li>Run in autocommit false mode, execute a number of inserts in one transaction,
and then explicitly issue a commit.</li>
<li>If your application allows an initial load into the table, you can use
-the import procedures to insert data into a table. <ph conref="tunconrefs.dita#prod/productshortname"></ph> will
+the import procedures to insert data into a table. <ph conref="../conrefs.dita#prod/productshortname"></ph> will
not log the individual inserts when loading into an empty table using these
-interfaces. See the <cite><ph conref="tunconrefs.dita#pub/citutilities"></ph> Guide</cite> for
+interfaces. See the <cite><ph conref="../conrefs.dita#pub/citutilities"></ph> Guide</cite> for
more information on the import procedures.</li>
</ul></p>
</conbody>
Modified: db/derby/docs/trunk/src/tuning/ctunperf17936.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf17936.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf17936.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf17936.dita Fri Mar 30 08:14:48 2007
@@ -25,12 +25,12 @@
</metadata>
</prolog>
<conbody>
-<p><ph conref="tunconrefs.dita#prod/productshortname"></ph> features crash recovery that restores the state of committed
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> features crash recovery that restores the state of committed
transactions in the event that the database exits unexpectedly, for example
during a power failure. The recovery processing happens the next time the
database is started after the unexpected exit. Your application can reduce
the amount of work that the database has to do to start up the next time by
-shutting it down in an orderly fashion. See "Shutting Down <ph conref="tunconrefs.dita#prod/productshortname"></ph> or an
-Individual Database" in the <cite><ph conref="tunconrefs.dita#pub/citdevelop"></ph></cite>. </p>
-<p>The <ph conref="tunconrefs.dita#prod/productshortname"></ph> utilities all perform an "orderly" shutdown.</p>
+shutting it down in an orderly fashion. See "Shutting Down <ph conref="../conrefs.dita#prod/productshortname"></ph> or an
+Individual Database" in the <cite><ph conref="../conrefs.dita#pub/citdevelop"></ph></cite>. </p>
+<p>The <ph conref="../conrefs.dita#prod/productshortname"></ph> utilities all perform an "orderly" shutdown.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunperf18705.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf18705.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf18705.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf18705.dita Fri Mar 30 08:14:48 2007
@@ -21,10 +21,10 @@
<prolog>
</prolog>
<conbody>
-<p>In <ph conref="tunconrefs.dita#prod/productshortname"></ph>, as with most relational database management systems, performing
+<p>In <ph conref="../conrefs.dita#prod/productshortname"></ph>, as with most relational database management systems, performing
an SQL request has two steps: compiling the request and executing it. When
you use prepared statements (<i>java.sql.PreparedStatement</i>) instead of statements (<i>java.sql.Statement</i>)
-you can help <ph conref="tunconrefs.dita#prod/productshortname"></ph> avoid unnecessary compilation, which saves time.
+you can help <ph conref="../conrefs.dita#prod/productshortname"></ph> avoid unnecessary compilation, which saves time.
In general, any query that you will use more than once should be a prepared
statement. </p>
<p>For more information, see <xref href="ctundepth29804.dita#ctundepth29804"/>.</p>
Modified: db/derby/docs/trunk/src/tuning/ctunperf22457.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf22457.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf22457.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf22457.dita Fri Mar 30 08:14:48 2007
@@ -21,6 +21,6 @@
<prolog>
</prolog>
<conbody>
-<p>This chapter lists tips for improving the performance of your <ph conref="tunconrefs.dita#prod/productshortname"></ph> application.
+<p>This chapter lists tips for improving the performance of your <ph conref="../conrefs.dita#prod/productshortname"></ph> application.
For a more in-depth discussion of performance, see <xref href="ctundepth39739.dita#ctundepth39739"/>.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunperf25864.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf25864.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf25864.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf25864.dita Fri Mar 30 08:14:48 2007
@@ -32,7 +32,7 @@
all the caches.</li>
<li><i><xref href="ctunperf10065.dita#ctunperf10065">Tune the size of database pages</xref>.</i> Using
large database pages has provided a performance improvement of <i>up to 50%</i>. There are also other storage parameters worth tweaking. If
-you use large database pages, increase the amount of memory available to <ph conref="tunconrefs.dita#prod/productshortname"></ph>.</li>
+you use large database pages, increase the amount of memory available to <ph conref="../conrefs.dita#prod/productshortname"></ph>.</li>
<li><i><xref href="ctunperf23868.dita#ctunperf23868">Avoid expensive queries</xref>.</i></li>
<li><i><xref href="ctunperf98197.dita#ctunperf98197">Use the appropriate getXXX and setXXX methods for the type</xref>.</i></li>
<li><i><xref href="ctunperf16556.dita#ctunperf16556">Tune database booting/class loading</xref>.</i> System
@@ -42,6 +42,6 @@
up insert performance.</li>
</ul>
<p>These tips might solve your particular performance problem. Be sure to
-visit the Support section of <ph conref="tunconrefs.dita#prod/productshortname"></ph>'s Web site for up-to-date performance
+visit the Support section of <ph conref="../conrefs.dita#prod/productshortname"></ph>'s Web site for up-to-date performance
tips and tricks.</p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunperf54492.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf54492.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf54492.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf54492.dita Fri Mar 30 08:14:48 2007
@@ -28,17 +28,17 @@
</prolog>
<conbody>
<p>You can increase the size of a database's data page cache, which consists
-of the data pages kept in memory. When <ph conref="tunconrefs.dita#prod/productshortname"></ph> can access a database page
+of the data pages kept in memory. When <ph conref="../conrefs.dita#prod/productshortname"></ph> can access a database page
from the cache instead of reading it from disk, it can return data much more
quickly.</p>
<p>The default size of the data page cache is 1000 pages. In a multi-user
environment, or in an environment where the user accesses a lot of data, increase
the size of the cache. You configure its size with the <xref href="rtunproper81359.dita#rtunproper81359">derby.storage.pageCacheSize</xref> property. For more information about
how to set this property and how to estimate memory use, see <i><xref href="rtunproper81359.dita#rtunproper81359">derby.storage.pageCacheSize</xref>.</i>
-<note><ph conref="tunconrefs.dita#prod/productshortname"></ph> can
+<note><ph conref="../conrefs.dita#prod/productshortname"></ph> can
run even with a small amount of memory and even with a small data page cache,
although it might perform poorly. Increasing the amount of memory available
-to <ph conref="tunconrefs.dita#prod/productshortname"></ph> and increasing the size of the data page cache improve performance.</note></p>
+to <ph conref="../conrefs.dita#prod/productshortname"></ph> and increasing the size of the data page cache improve performance.</note></p>
<p>In addition, you might want to prime <i>all</i> the caches
in the background to make queries run faster when the user gets around to
running them.</p>
Modified: db/derby/docs/trunk/src/tuning/ctunperf816059.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf816059.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf816059.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf816059.dita Fri Mar 30 08:14:48 2007
@@ -27,7 +27,7 @@
</prolog>
<conbody>
<p>Using large database pages benefits database performance, notably decreasing
-I/O time. <ph conref="tunconrefs.dita#prod/productshortname"></ph> autotunes the database pagesize. If you have long columns, the default pagesize for the table is set to 32K. Otherwise, the default is 4K. You can change
+I/O time. <ph conref="../conrefs.dita#prod/productshortname"></ph> autotunes the database pagesize. If you have long columns, the default pagesize for the table is set to 32K. Otherwise, the default is 4K. You can change
the default database page size with the <i><xref href="rtunproper40688.dita#rtunproper40688">derby.storage.pageSize</xref></i> property. For example:
<codeblock><b>derby.storage.pageSize=8192</b></codeblock></p>
<note>Large database pages require more memory.</note>
Modified: db/derby/docs/trunk/src/tuning/ctunperf816635.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunperf816635.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunperf816635.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunperf816635.dita Fri Mar 30 08:14:48 2007
@@ -25,9 +25,9 @@
</metadata>
</prolog>
<conbody>
-<p>The structure of your classpath can affect <ph conref="tunconrefs.dita#prod/productshortname"></ph> startup time and
+<p>The structure of your classpath can affect <ph conref="../conrefs.dita#prod/productshortname"></ph> startup time and
the time required to load a particular class. </p>
-<p>The classpath is searched linearly, so locate <ph conref="tunconrefs.dita#prod/productshortname"></ph>'s libraries <i>at the beginning of the classpath</i> so that they are found
+<p>The classpath is searched linearly, so locate <ph conref="../conrefs.dita#prod/productshortname"></ph>'s libraries <i>at the beginning of the classpath</i> so that they are found
first. If the classpath first points to a directory that contains multiple
-files, booting <ph conref="tunconrefs.dita#prod/productshortname"></ph> can be very slow. </p>
+files, booting <ph conref="../conrefs.dita#prod/productshortname"></ph> can be very slow. </p>
</conbody></concept>
Modified: db/derby/docs/trunk/src/tuning/ctunproper22250.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunproper22250.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunproper22250.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunproper22250.dita Fri Mar 30 08:14:48 2007
@@ -20,7 +20,7 @@
-->
<concept id="ctunproper22250" xml:lang="en-us">
<title>Derby properties</title>
-<shortdesc>The <ph conref="tunconrefs.dita#prod/productshortname"></ph> properties
+<shortdesc>The <ph conref="../conrefs.dita#prod/productshortname"></ph> properties
are used for configuring the system and database, as well as for diagnostics
such as logging statements, and monitoring and tracing locks.</shortdesc>
<prolog><metadata>
@@ -28,12 +28,12 @@
</keywords>
</metadata></prolog>
<conbody>
-<p>This section includes all of the core <ph conref="tunconrefs.dita#prod/productshortname"></ph> properties. <note>When
+<p>This section includes all of the core <ph conref="../conrefs.dita#prod/productshortname"></ph> properties. <note>When
setting properties that have boolean values, be sure to trim extra spaces
around the word <i>true</i>. Extra spaces around the word <i>true</i> cause
the property to be set to false.</note></p>
<p><xref href="ctunproper22250.dita#ctunproper22250/rtunproper24108"></xref> summarizes
-the general <ph conref="tunconrefs.dita#prod/productshortname"></ph> properties.
+the general <ph conref="../conrefs.dita#prod/productshortname"></ph> properties.
In this table, S stands for system-wide, D stands for database-wide, and C
indicates the value persists with newly created conglomerates. X means yes.
<table frame="all" id="rtunproper24108" pgwide="0"><title>Derby properties</title>
@@ -218,7 +218,7 @@
</table></p>
<p id="rtunproper97948">* See the main page for this property for information
about when changes to the property are dynamic.</p>
-<p>There are additional properties associated with the <ph conref="tunconrefs.dita#prod/productshortname"></ph> tools.
-For more information about tool-specific properties, see the <i><ph conref="tunconrefs.dita#pub/citutilities"></ph> Guide</i>.</p>
+<p>There are additional properties associated with the <ph conref="../conrefs.dita#prod/productshortname"></ph> tools.
+For more information about tool-specific properties, see the <i><ph conref="../conrefs.dita#pub/citutilities"></ph> Guide</i>.</p>
</conbody>
</concept>
Modified: db/derby/docs/trunk/src/tuning/ctunproper51399.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunproper51399.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunproper51399.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunproper51399.dita Fri Mar 30 08:14:48 2007
@@ -21,7 +21,7 @@
<title>Scope of Derby properties</title>
<prolog></prolog>
<conbody>
-<p>A property in <ph conref="tunconrefs.dita#prod/productshortname"></ph> belongs
+<p>A property in <ph conref="../conrefs.dita#prod/productshortname"></ph> belongs
to one or more of these scopes:<ul id="i1008301">
<li id="rtunproper41229"><i>system-wide</i> <p>System-wide properties apply
to an entire system, including all its databases and tables if applicable.</p><ul
@@ -31,8 +31,8 @@
properties set in the <i>derby.properties</i> file.</p></li>
<li>Set in the <i>derby.properties</i> file<p>The <i>derby.properties</i> file
is an optional file that can be created to set properties at the system level
-when the <ph conref="tunconrefs.dita#prod/productshortname"></ph> driver is
-loaded. <ph conref="tunconrefs.dita#prod/productshortname"></ph> looks for
+when the <ph conref="../conrefs.dita#prod/productshortname"></ph> driver is
+loaded. <ph conref="../conrefs.dita#prod/productshortname"></ph> looks for
this file in the directory defined by the derby.system.home property. Any
property except derby.system.home can be set by including it in the <i>derby.properties</i> file.</p></li>
</ul></li>
Modified: db/derby/docs/trunk/src/tuning/ctunpropref1002477.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctunpropref1002477.dita?view=diff&rev=524117&r1=524116&r2=524117
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctunpropref1002477.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctunpropref1002477.dita Fri Mar 30 08:14:48 2007
@@ -22,9 +22,9 @@
<title>About this guide</title>
<prolog></prolog>
<conbody>
-<p>For general information about the <ph conref="tunconrefs.dita#prod/productshortname"></ph> documentation,
+<p>For general information about the <ph conref="../conrefs.dita#prod/productshortname"></ph> documentation,
such as a complete list of books, conventions, and further reading, see <cite><ph
-conref="tunconrefs.dita#pub/citgetstart"></ph></cite>.</p>
+conref="../conrefs.dita#pub/citgetstart"></ph></cite>.</p>
</conbody>
</concept>