Adjust cost_merge_append() to reflect use of binaryheap_replace_first().

Commit 7a2fe9bd0 improved merge append so that replacement of a tuple
takes log(N) operations, not twice log(N).  Since cost_merge_append knew
about that explicitly, we should adjust it.  This probably makes little
difference in practice, but the obsolete comment is confusing.

Ideally this would have been put in in 9.3 with the underlying behavior
change; but I'm not going to back-patch it, since there's some small chance
of changing a plan choice that somebody's optimized for.

Thomas Munro

Discussion: <CAEepm=0WQBSvuYcMOUj4Ga4NXpu2J=ejZcE=e=eiTjTX-6_gDw@mail.gmail.com>

diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index 2a49639f1254a1e564169ff0cb4587a79b40f823..e42895dc31c6ba8e5eb621a72d61e14d5506d56f 100644 (file)
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -1577,8 +1577,7 @@ cost_sort(Path *path, PlannerInfo *root,
  * at any given instant holds the next tuple from each stream.  If there
  * are N streams, we need about N*log2(N) tuple comparisons to construct
  * the heap at startup, and then for each output tuple, about log2(N)
- * comparisons to delete the top heap entry and another log2(N) comparisons
- * to insert its successor from the same stream.
+ * comparisons to replace the top entry.
  *
  * (The effective value of N will drop once some of the input streams are
  * exhausted, but it seems unlikely to be worth trying to account for that.)
@@ -1619,7 +1618,7 @@ cost_merge_append(Path *path, PlannerInfo *root,
    startup_cost += comparison_cost * N * logN;
 
    /* Per-tuple heap maintenance cost */
-   run_cost += tuples * comparison_cost * 2.0 * logN;
+   run_cost += tuples * comparison_cost * logN;
 
    /*
     * Also charge a small amount (arbitrarily set equal to operator cost) per