On Mon, 2007-06-04 at 14:41 -0400, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > One of the main reasons for the implementation was to allow larger > > queries to work faster by utilising multiple temp tablespaces for the > > same query. > > > The original ideal implementation was to use round-robin/cyclic > > selection, which allows much better usage in the above case. > > Really? What if multiple backends are all hitting the same tablespaces > in the same order? A random selection seems much less likely to risk > having any self-synchronizing behavior.
I'd like a single backend to never reuse a temp tablespace that is actively being used so that large queries won't randomly conflict with themselves. That's pretty certain to draw complaints, IMHO. We can do this two ways - cycle thru temp tablespaces, as originally suggested (not by me...) - pick a random tablespace **other than ones already in active use** -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
