Weird issue. I'm trying to figure out how the connection pool can add an overhead to a single query. The only case I can think is if you use a network storage engine (Federated, Connect, Spider) pointing to tables on localhost. Is this the case? More likely... are you sure this problem is caused by the connection pool? * After the first execution, do a SHOW STATUS. Then FLUSH STATUS. Then execute again and, if it takes long time, do another SHOW STATUS. Post your results here, so we can see what happened. * While the query takes a long time, try a SHOW PROCESSLIST from another client. See if the connection is waiting for a lock. Regards Federico -------------------------------------------- Mar 14/6/16, Stu Smith <stu26code@gmail.com> ha scritto: Oggetto: [Maria-discuss] Odd behavior with query and connection pool A: maria-discuss@lists.launchpad.net Data: Martedì 14 giugno 2016, 03:36 Hello, Forgive me for reporting this on the behalf of some other developers, I will gather more details as needed. But the basic problem we're having is with a query that: - is always fast the first time ( < 3 seconds ) - is very slow the following time, when using a connection pool (~ 30 seconds) - is pretty fast the following time, when not using a connection pool (5 or 6 seconds) This is even on a single DB with no other load. It's a fairly complicated query with sub queries, grouping, and such. I've been told it creates two temp tables. I know this is not a whole lot to go one - but are there any pointer for connection pool vs no connection pool on a lightly loaded DB? This was actually tried and reproduced with multiple connection pools - hikari-db, c3p0, and apache connection pool. Take care, -stu -----Segue allegato----- _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp