Re: Test coverage for external sorting

Tom,

> BTW, as for your original question about performance, the current
> external sort algorithm is mainly designed to conserve disk space,
> not to be as fast as possible.  It could probably be a good bit faster
> if we didn't mind taking twice as much space (mainly because the
> physical disk access pattern would be a lot less random).  But I know
> we will get push-back if we try to revert to doing that.

We could do it as a compile-time option or a GUC.  I know I wouldn't mind 
taking extra disk space if my sorts ran faster on very large tables.   
Currently, building a new btree index on a 100GB table takes about 2 hours on 
a v40z.  And that's not becuase of I/O; disk bandwidth is less than 20% used.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco