Avoid assuming that statistics for a parent relation reflect the properties of

the union of its child relations as well.  This might have been a good idea
when it was originally coded, but it's a fatally bad idea when inheritance is
being used for partitioning.  It's better to have no stats at all than
completely misleading stats.  Per report from Mark Liberman.

The bug arguably exists all the way back, but I've only patched HEAD and 8.1
because we weren't particularly trying to support partitioning before 8.1.

Eventually we ought to look at deriving union statistics instead of just
punting, but for now the drop kick looks good.

1 files changed, 8 insertions, 1 deletions

diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index f35e87962da..de82c3df8d0 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.145 2006/04/30 18:30:39 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.146 2006/05/02 04:34:18 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -274,6 +274,13 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
 				 errmsg("SELECT FOR UPDATE/SHARE is not supported for inheritance queries")));
 
 	/*
+	 * We might have looked up indexes for the parent rel, but they're
+	 * really not relevant to the appendrel.  Reset the pointer to avoid
+	 * any confusion.
+	 */
+	rel->indexlist = NIL;
+
+	/*
 	 * Initialize to compute size estimates for whole append relation
 	 */
 	rel->rows = 0;