On Thu, 2007-12-20 at 01:26 +0000, Gregory Stark wrote:
> I suspect most of that is spent just copying the data around. Which would not
> be helped by having multiple threads doing the copying -- and in fact might be
> exacerbated if it required an extra copy to consolidate all the data in the
> end.
The theory is that it could be helped by multiple threads, because of
the memory latency.
> How long does a "explain analyze sinmple select * from sorter" take?
2 seconds, but the table is already in cache I'm sure (since it's so
small).
> Note that speeding up a query from 20s to 5s isn't terribly useful. If it's
> OLTP you can't be using all your cores for each user anyways. And if it's DSS
> 20s isn't a problem.
I'm not pushing for parallel sort, I'm just brainstorming. I think Ron's
idea has merit, but I realize it also has limitations.
> Where parallel processing like this becomes attractive is when you're running
> a 2 hour query on a machine sequentially running scheduled batch jobs which
> can be sped up to 30 minutes. But in that case you're almost certainly being
> limited by your disk bandwidth, not your cpu speed.
Are you sure that's always the case? My test seemed to indicate that
sorting took longer than it would to read the file from disk.
Regards,Jeff Davis
