Be more tense about not creating tuplestores with randomAccess = true unless

backwards scan could actually happen.  In particular, pass a flag to
materialize-mode SRFs that tells them whether they need to require random
access.  In passing, also suppress unneeded backward-scan overhead for a
Portal's holdStore tuplestore.  Per my proposal about reducing I/O costs for
tuplestores.

1 files changed, 4 insertions, 2 deletions

diff --git a/contrib/xml2/xpath.c b/contrib/xml2/xpath.c
index 39908494f3e..b2f3342f737 100644
--- a/contrib/xml2/xpath.c
+++ b/contrib/xml2/xpath.c
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/contrib/xml2/xpath.c,v 1.20 2008/05/17 01:28:22 adunstan Exp $ 
+ * $PostgreSQL: pgsql/contrib/xml2/xpath.c,v 1.21 2008/10/29 00:00:38 tgl Exp $ 
  *
  * Parser interface for DOM-based parser (libxml) rather than
    stream-based SAX-type parser */
@@ -688,7 +688,9 @@ xpath_table(PG_FUNCTION_ARGS)
 	 * Create the tuplestore - work_mem is the max in-memory size before a
 	 * file is created on disk to hold it.
 	 */
-	tupstore = tuplestore_begin_heap(true, false, work_mem);
+	tupstore =
+		tuplestore_begin_heap(rsinfo->allowedModes & SFRM_Materialize_Random,
+							  false, work_mem);
 
 	MemoryContextSwitchTo(oldcontext);