db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaa...@apache.org
Subject svn commit: r1095466 - in /db/derby/docs/branches/10.8/src/ref: rrefsysxplain_resultset_timings.dita rrefsysxplain_resultsets.dita rrefsysxplain_scan_props.dita rrefsysxplain_sort_props.dita rrefsysxplain_statements.dita
Date Wed, 20 Apr 2011 17:40:34 GMT
Author: chaase3
Date: Wed Apr 20 17:40:33 2011
New Revision: 1095466

URL: http://svn.apache.org/viewvc?rev=1095466&view=rev
DERBY-5198 XPLAIN table documentation needs some cleanup

Merged DERBY-5198.diff to 10.8 code branch from trunk revision 1095463.


Modified: db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultset_timings.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultset_timings.dita?rev=1095466&r1=1095465&r2=1095466&view=diff
--- db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultset_timings.dita (original)
+++ db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultset_timings.dita Wed Apr 20 17:40:33
@@ -160,9 +160,9 @@ rows in this result set.</entry>
 <entry colname="4">true</entry>
 <entry colname="5">For result sets which involve a materialization of
     a temporary intermediate result set, this value is the time it took to
-    create the materialized result set, in milliseconds. I think this
+    create the materialized result set, in milliseconds. This materialization
     may occur with hash joins where the number of rows in the intermediate
-result is too large to hold in memory?</entry>
+result is too large to hold in memory.</entry>
 <entry colname="1">TEMP_CONG_FETCH_TIME</entry>

Modified: db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultsets.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultsets.dita?rev=1095466&r1=1095465&r2=1095466&view=diff
--- db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultsets.dita (original)
+++ db/derby/docs/branches/10.8/src/ref/rrefsysxplain_resultsets.dita Wed Apr 20 17:40:33
@@ -86,8 +86,7 @@ colnum="5" colwidth="29*"/>
 <entry colname="4">false</entry>
 <entry colname="5">A code indicating what type of result set these statistics
     are for.
-    Common result set types include: TABLESCAN, INDEXSCAN, PROJECTION, etc.
-Should I try to list all the result set types here?</entry>
+    Common result set types include TABLESCAN, INDEXSCAN, and PROJECTION.</entry>
 <entry colname="1">OP_DETAILS</entry>
@@ -190,9 +189,8 @@ rows which were inserted, updated, or de
 <entry colname="5">The column is only non-null for INSERT, UPDATE, and
     DELETE result sets. For those result sets, this column holds 'Y' if the
     INSERT/UPDATE/DELETE is being performed using deferred change semantics,
-    and holds 'N' otherwise. I think that deferred change semantics are used
-    when there is self-referencing going on, and we must avoid the
-    "Halloween" problem of processing the rows multiple times.
+    and holds 'N' otherwise. Deferred change semantics are used
+    when self-referencing is taking place.

Modified: db/derby/docs/branches/10.8/src/ref/rrefsysxplain_scan_props.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/ref/rrefsysxplain_scan_props.dita?rev=1095466&r1=1095465&r2=1095466&view=diff
--- db/derby/docs/branches/10.8/src/ref/rrefsysxplain_scan_props.dita (original)
+++ db/derby/docs/branches/10.8/src/ref/rrefsysxplain_scan_props.dita Wed Apr 20 17:40:33
@@ -181,10 +181,8 @@ scan which were found to be rows that we
 <entry colname="2">INTEGER</entry>
 <entry colname="3">10</entry>
 <entry colname="4">true</entry>
-<entry colname="5">I think this is the number of pages fetched at a time
-    when the scan is retrieving pages from disk? I expected this to be 16
-    when doing a TABLESCAN, and 1 when doing an INDEXSCAN, but I've also seen
-it be 16 for INDEXSCAN?</entry>
+<entry colname="5">The number of pages fetched at a time
+    when the scan is retrieving pages from disk.</entry>
 <entry colname="1">START_POSITION</entry>

Modified: db/derby/docs/branches/10.8/src/ref/rrefsysxplain_sort_props.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/ref/rrefsysxplain_sort_props.dita?rev=1095466&r1=1095465&r2=1095466&view=diff
--- db/derby/docs/branches/10.8/src/ref/rrefsysxplain_sort_props.dita (original)
+++ db/derby/docs/branches/10.8/src/ref/rrefsysxplain_sort_props.dita Wed Apr 20 17:40:33
@@ -77,7 +77,7 @@ which required this sort to be performed
 <entry colname="4">true</entry>
 <entry colname="5">A code indicating the type of sort that was performed.
     The code values include 'IN' for an internal sort, and 'EX' for an
-    external sort. I think that an internal sort is one which was entirely
+    external sort. An internal sort is one which was entirely
     performed in-memory and did not overflow to any temporary files, while an
 external sort used one or more external files.</entry>

Modified: db/derby/docs/branches/10.8/src/ref/rrefsysxplain_statements.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/ref/rrefsysxplain_statements.dita?rev=1095466&r1=1095465&r2=1095466&view=diff
--- db/derby/docs/branches/10.8/src/ref/rrefsysxplain_statements.dita (original)
+++ db/derby/docs/branches/10.8/src/ref/rrefsysxplain_statements.dita Wed Apr 20 17:40:33
@@ -73,9 +73,8 @@ colnum="5" colwidth="29*"/>
 <entry colname="3">128</entry>
 <entry colname="4">true</entry>
 <entry colname="5">The name of the associated query or statement. This value
-    is NULL if the user did not assign a name. I'm not sure how the
-    user assigns a name to a statement, perhaps by
-    calling Statement.setCursorName()?</entry>
+    is NULL if the user did not assign a name (by calling
+    <i>java.sql.Statement.setCursorName()</i>).</entry>
 <entry colname="1">STMT_TYPE</entry>

View raw message