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