From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Polyphase merge is obsolete |
Date: | 2016-10-12 18:25:43 |
Message-ID: | 7ad9d969-f25c-2c54-a9df-4bea09a11301@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/12/2016 08:27 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> The beauty of the polyphase merge algorithm is that it allows reusing
>> input tapes as output tapes efficiently ... So the whole idea of trying to
>> efficiently reuse input tapes as output tapes is pointless.
>
> It's been awhile since I looked at that code, but I'm quite certain that
> it *never* thought it was dealing with actual tapes. Rather, the point of
> sticking with polyphase merge was that it allowed efficient incremental
> re-use of temporary disk files, so that the maximum on-disk footprint was
> only about equal to the volume of data to be sorted, rather than being a
> multiple of that. Have we thrown that property away?
No, there's no difference to that behavior. logtape.c takes care of
incremental re-use of disk space, regardless of the merging pattern.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2016-10-12 18:54:18 | Re: pg_dump getBlobs query broken for 7.3 servers |
Previous Message | Christoph Berg | 2016-10-12 18:20:44 | Re: Non-empty default log_line_prefix |