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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
