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