From eac4f3002c5be458e44ab45e11435e8fc1a3b1e0 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 15 Feb 2001 17:46:40 +0000 Subject: [PATCH] Update a couple of obsolete comments. --- src/backend/optimizer/path/costsize.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index 18623b7030..5f01cc64b4 100644 --- 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) -- 2.39.5