Tom, On 3/9/06 9:44 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> I think this argumentation hinges on some irrational aversion to the > word "tape". Given adequate work_mem, the CVS-tip behavior is exactly > what you propose already (at least for the cases where we don't need > random access to the sort result). Nope. There's the matter of this thing called logtape.c, in addition to the use of the "tape" as a means of grouping runs. In the current implementation, runs are not tapes, and tapes as used in the implementation are an abstraction that only obscures the underlying processes in a meaningful way. My objection to tapes is a rational one, and we have internally demonstrated that by eliminating logtape.c and large hunks of tape algorithm related code, we get slightly faster performance with 2,000 fewer lines of code, ergo, the code is not useful. We did this in two days of work, and in the process uncovered the fact that access was always set to RANDOM, the import of which we've seen discussed here. > AFAICS the only result of removing > the support for multipass merge is that the code would fail, rather than > run slowly, if it didn't have adequate work_mem for a particular > problem. Somehow I don't see that as an improvement. I would only suggest that we replace the existing algorithm with one that will work regardless of (reasonable) memory requirements. Perhaps we can agree that at least 1MB of RAM for external sorting will always be available and proceed from there? - Luke ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings