Fix set_rel_width() to do something reasonable with non-Var items in a
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 11 Jul 2009 04:09:33 +0000 (04:09 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 11 Jul 2009 04:09:33 +0000 (04:09 +0000)
RelOptInfo targetlist.  It used to be that the only possibility other than
a Var was a RowExpr representing a whole-row child Var, but as of 8.4's
expanded ability to flatten appendrel members, we can get arbitrary expressions
in there.  Use the expression's type info and get_typavgwidth() to produce
an at-least-marginally-sane result.  Note that get_typavgwidth()'s fallback
estimate (32 bytes) is the same as what was here before, so there will be
no behavioral change for RowExprs.  Noted while looking at recent gripe
about constant quals pushed down to FunctionScan appendrel members ...
not only were we failing to recognize the constant qual, we were getting
the width estimate wrong :-(

src/backend/optimizer/path/costsize.c

index ab5a2671b221e75bcd5d2bf86a2a400dbc5c8c64..fcbb8cabad833e966c64ced91ff739519f199517 100644 (file)
@@ -2997,8 +2997,16 @@ set_rel_width(PlannerInfo *root, RelOptInfo *rel)
                }
                else
                {
-                       /* For now, punt on whole-row child Vars */
-                       tuple_width += 32;      /* arbitrary */
+                       /*
+                        * We could be looking at an expression pulled up from a subquery,
+                        * or a ROW() representing a whole-row child Var, etc.  Do what
+                        * we can using the expression type information.
+                        */
+                       int32           item_width;
+
+                       item_width = get_typavgwidth(exprType(node), exprTypmod(node));
+                       Assert(item_width > 0);
+                       tuple_width += item_width;
                }
        }
        Assert(tuple_width >= 0);