On Sun, Feb 7, 2016 at 10:51 AM, Greg Stark <st...@mit.edu> wrote: >> > You don't want to change the behavior of the current patch for the >> > second or subsequent run; that should remain a quicksort, pure and >> > simple. Do I have that right? >> >> Yes. > > I'm not even sure this is necessary. The idea of missing out on > producing a single sorted run sounds bad but in practice since we > normally do the final merge on the fly there doesn't seem like there's > really any difference between reading one tape or reading two or three > tapes when outputing the final results. There will be the same amount > of I/O happening and a 2-way or 3-way merge for most data types should > be basically free.
I basically agree with you, but it seems possible to fix the regression (generally misguided though those regressed cases are). It's probably easiest to just fix it. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
