George Cherian <[EMAIL PROTECTED]> wrote on 08/22/2005 04:46:02 AM: > On Mon, Aug 22, 2005 at 01:46:23PM +0530, George Cherian wrote: > > > > > > I need to run a particular 'select' on multiple machines, and > then reorder them. The query is: 'select * from table where > parent_name = 'parent' order by name limit 10. This query has to be > sent to 10 servers - in series, synchronously - the result (total of > 100), should be resorted (each of the ten rows from the server will > be sorted, but the total would not be in order), and then discard > the 90, and return only the first 10 rows. > > > > Now that I thought it over, running the queries serially in a > synchronous fashion is pure insanity. Actually it should create 10 > threads, execute the 10 selects simultaneously, collate the results, > order them, dump the 90 and return the 10. Thus this would be > trivially able to scale to at least 700 servers simultaneously on a > 256MB ram machine. Does such a solution exist now? > > Thanks a lot. >
You are correct in your analysis that you would get better performance if you ran the queries asynchronously. Just remember that each query thread will need its *own* connection. Even if you are querying two databases on the same server, each connection can only handle one query/action/statement at a time. It is "VERY UNWISE" to share connections between threads unless you ensure (by some application level synchronization like a mutex) that only one thread at a time is trying to use any one connection. Are there clients with this kind of asynchronous query capacity? Probably, but they have been specially built just for the application they support. You are probably going to need to create your own client in order to collect and correlate your separate queries. There are several connection libraries available, use whichever fits into your programming model. Shawn Green Database Administrator Unimin Corporation - Spruce Pine