| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Subject: | Re: Parallel tuplesort (for parallel B-Tree index creation) |
| Date: | 2016-09-06 19:42:42 |
| Message-ID: | CAM3SWZSCGz-nWEmEZTPVu-0SYdSRQwVLXo=bowtVgoP=CcY3Vg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 6, 2016 at 12:39 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Tue, Sep 6, 2016 at 12:08 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>> I attach a patch that changes how we maintain the heap invariant
>>> during tuplesort merging.
>
>> Nice!
>
> Thanks!
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. I hate to say it, but I have to
wonder if we shouldn't get rid of the new-to-9.6
replacement_sort_tuples because of this, and completely kill
replacement selection. I'm not going to go on about it, but that seems
sensible to me.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-09-06 19:51:35 | Re: Bug in 9.6 tuplesort batch memory growth logic |
| Previous Message | Peter Geoghegan | 2016-09-06 19:39:39 | Re: Parallel tuplesort (for parallel B-Tree index creation) |