Update a couple of obsolete comments.

diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index 18623b7030d1601c18c1ae7ef4a323895e09a12a..5f01cc64b45c7545222c8a168812120505c07190 100644 (file)
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -34,8 +34,7 @@
  * Note that a relation's rows count (and, by extension, a Plan's plan_rows)
  * are set without regard to any LIMIT, so that this equation works properly.
  * (Also, these routines guarantee not to set the rows count to zero, so there
- * will be no zero divide.)  RelOptInfos, Paths, and Plans themselves never
- * account for LIMIT.
+ * will be no zero divide.)  The LIMIT is applied as a separate Plan node.
  *
  *
  * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
@@ -96,15 +95,10 @@ static double page_size(double tuples, int width);
  * cost_seqscan
  *       Determines and returns the cost of scanning a relation sequentially.
  *
- * If the relation is a temporary to be materialized from a query
- * embedded within a data field (determined by 'relid' containing an
- * attribute reference), then a predetermined constant is returned (we
- * have NO IDEA how big the result of a POSTQUEL procedure is going to be).
- *
  * Note: for historical reasons, this routine and the others in this module
  * use the passed result Path only to store their startup_cost and total_cost
  * results into.  All the input data they need is passed as separate
- * parameters, even though much of it could be extracted from the result Path.
+ * parameters, even though much of it could be extracted from the Path.
  */
 void
 cost_seqscan(Path *path, RelOptInfo *baserel)