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

Reply via email to