Simon Riggs <[EMAIL PROTECTED]> writes: > I think it would be useful to think about exactly what type of > query/activity we are looking to improve the performance on. That way we > can understand the benefit of this proposal and take some baseline > measurements to analyse what is happening for those cases.
I find the focus on sequential scans, index scans, etc. quite odd when you're discussing parallel query processing. The whole goal of parallel query processing is to bring more *cpu* to bear on the problem. That's going to be most relevant when you're cpu bound, not i/o bound. The queries I would expect to be helped most by parallel query processing are queries that involve sorting. For example, a big merge join with two sorts on either side could perform the two sorts simultaneously. If they provide the results of the final pass to a third thread it can execute the merge join and the rest of the query plan while the sorts are still executing on two other processors. -- greg ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
