Обсуждение: Leftover reference to replacement selection 1 run case

While reviewing the parallel CREATE INDEX patch, I noticed that commit
8b304b8b omitted to remove a comment that it made obsolete.

Attached patch removes the comment.

-- 
Peter Geoghegan

On Fri, Dec 8, 2017 at 6:41 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> While reviewing the parallel CREATE INDEX patch, I noticed that commit
> 8b304b8b omitted to remove a comment that it made obsolete.
>
> Attached patch removes the comment.

I had to think about this for a while.  I could see that the comment
is now wrong, but initially I wasn't sure why we didn't care about the
optimization any more.  Eventually I had a thought: it's now
impossible to end up with only one tape, because each tape now always
contains the output of one quicksort operation, and if we only did one
quicksort operation, it would have been an in-memory sort and there
would be no tapes anyway.  Once we create a first tape, we've overrun
work_mem, so there will always be a second one.

Does that sound right?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Dec 12, 2017 at 6:44 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> Yes, you have that right. Per dumptuples(), even the zero tuple run edge
> case will still write a run marker, and will therefore still consume a tape.
> We must have at least two initial runs to merge. (though dummy runs for non
> final merges are a slightly different matter.)

OK, committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company