<p dir="ltr"><br /> On 30 Jan 2016 8:27 am, "Greg Stark" <<a href="mailto:stark@mit.edu">stark@mit.edu</a>>
wrote:<br/> ><br /> ><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
easyto construct cases where this technique regresses,<br /> > > and a large percentage of those cases are
preciselythose where<br /> > > replacement selection would have produced a single run, avoiding the<br /> >
>merge step altogether. <br /> ><br /> > Now that avoiding the merge phase altogether didn't necessarily
representany actual advantage.<br /> ><br /> > We don't find out we've avoided the merge phase until the entire
runhas been spiked to disk. <p dir="ltr">Hm, sorry about the phone typos. I thought I proofread it as I went but
obviouslynot that effectively...
