On Tue, Sep 6, 2016 at 10:28 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: >> BTW, the way that k-way merging is made more efficient by this >> approach makes the case for replacement selection even weaker than it >> was just before we almost killed it. > > > This also makes the replacement selection cheaper, no?
Well, maybe, but the whole idea behind replacement_sort_tuples (by which I mean the continued occasional use of replacement selection by Postgres) was that we hope to avoid a merge step *entirely*. This new merge shift down heap patch could make the merge step so cheap as to be next to free anyway (in the even of presorted input), so the argument for replacement_sort_tuples is weakened further. It might always be cheaper once you factor in that the TSS_SORTEDONTAPE path for returning tuples to caller happens to not be able to use batch memory, even with something like collated text. And, as a bonus, you get something that works just as well with an inverse correlation, which was traditionally the worst case for replacement selection (it makes it produce runs no larger than those produced by quicksort). Anyway, I only mention this because it occurs to me. I have no desire to go back to talking about replacement selection either. Maybe it's useful to point this out, because it makes it clearer still that severely limiting the use of replacement selection in 9.6 was totally justified. -- 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
