The reason could be caching, swapping or things like that. When you execute 4 queries concurrently in different connections each of them have to create its own memory cache of database pages. Reading data into cache involves syscalls to Linux kernel for reading from disk. Although Linux has its own disk cache and most probably physically reads from disk only once all this calls can still interfere with each other. When you execute 4 queries sequentially on the same connection they all use the same memory cache which is filled in first query and used in all consecutive ones. Because of 4 memory caches in the concurrent case there could be a problem with available physical memory and if swapping takes place then things get a lot slower...
But it's all just theoretical guesses. Run strace on both your applications and see what syscalls take so long in concurrent case or where between syscalls too much time is spent. Pavel On Thu, Feb 24, 2011 at 4:52 AM, Maddy <im4frie...@gmail.com> wrote: > Hi, > I have 4 "SELECT" queries which are accessing same table. > When I executed these queries concurrently using pthreads in Linux, it took > approximate 10 Seconds. > But same 4 queries executed sequentially it only took 2 seconds. > Total Rows in table are 100000. > Sample query is "SELECT column1, sum(column2) from TABLE_NAME;" > > What can be the reason behind this? > > > Thanks, > Madhav > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
