Thread: 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
Attachment
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
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.)
--
Peter Geoghegan
(Sent from my phone)
Peter Geoghegan
(Sent from my phone)
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