|
41 | 41 | * Portions Copyright (c) 1994, Regents of the University of California |
42 | 42 | * |
43 | 43 | * IDENTIFICATION |
44 | | - * $Header: /cvsroot/pgsql/src/backend/optimizer/path/costsize.c,v 1.69 2001/03/22 03:59:34 momjian Exp $ |
| 44 | + * $Header: /cvsroot/pgsql/src/backend/optimizer/path/costsize.c,v 1.70 2001/04/25 22:04:37 tgl Exp $ |
45 | 45 | * |
46 | 46 | *------------------------------------------------------------------------- |
47 | 47 | */ |
@@ -443,14 +443,22 @@ cost_nestloop(Path *path, |
443 | 443 | /* cost of source data */ |
444 | 444 |
|
445 | 445 | /* |
446 | | - * NOTE: we assume that the inner path's startup_cost is paid once, |
447 | | - * not over again on each restart.This is certainly correct if the |
448 | | - * inner path is materialized.Are there any cases where it is wrong? |
| 446 | + * NOTE: clearly, we must pay both outer and inner paths' startup_cost |
| 447 | + * before we can start returning tuples, so the join's startup cost |
| 448 | + * is their sum. What's not so clear is whether the inner path's |
| 449 | + * startup_cost must be paid again on each rescan of the inner path. |
| 450 | + * This is not true if the inner path is materialized, but probably |
| 451 | + * is true otherwise. Since we don't yet have clean handling of the |
| 452 | + * decision whether to materialize a path, we can't tell here which |
| 453 | + * will happen. As a compromise, charge 50% of the inner startup cost |
| 454 | + * for each restart. |
449 | 455 | */ |
450 | 456 | startup_cost+=outer_path->startup_cost+inner_path->startup_cost; |
451 | 457 | run_cost+=outer_path->total_cost-outer_path->startup_cost; |
452 | 458 | run_cost+=outer_path->parent->rows* |
453 | 459 | (inner_path->total_cost-inner_path->startup_cost); |
| 460 | +if (outer_path->parent->rows>1) |
| 461 | +run_cost+= (outer_path->parent->rows-1)*inner_path->startup_cost; |
454 | 462 |
|
455 | 463 | /* |
456 | 464 | * Number of tuples processed (not number emitted!). If inner path is |
|