On 29 Jan 2016 11:58 pm, "Robert Haas" <robertmh...@gmail.com> wrote: > It > seems pretty easy to construct cases where this technique regresses, > and a large percentage of those cases are precisely those where > replacement selection would have produced a single run, avoiding the > merge step altogether.
Now that avoiding the merge phase altogether didn't necessarily represent any actual advantage. We don't find out we've avoided the merge phase until the entire run has been spiked to disk. Then we need to read it back in from disk to serve up those tuples. If we have tapes to merge but can do then in a single pass we do that lazily and merge as needed when we serve up the tuples. I doubt there's any speed difference in reading two sequential streams with our buffering over one especially in the midst of a quiet doing other i/o. And N extra comparisons is less than the quicksort advantage. If we could somehow predict that it'll be a single output run that would be a huge advantage. But having to spill all the tuples and then find out isn't really helpful.
