Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS

On 15/03/12 10:16, Martin J. Evans wrote: On 14/03/2012 10:20, Tim Bunce wrote: On Wed, Mar 14, 2012 at 08:24:36AM +0100, H.Merijn Brand wrote: On Tue, 13 Mar 2012 21:44:06 +, Tim Buncetim.bu...@pobox.com wrote: On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: The second

Re: Having a code ref executed when result set is all fetched

On Wed, Mar 14, 2012 at 01:35:21PM +0100, Elizabeth Mattijsen wrote: Maybe some background first: I'm working on code that does queries on large tables. To be able to support the growth of these tables, we need to shard the tables to multiple database servers. One way to shard this

more_results was Having a code ref executed when result set is all fetched

On 15/03/12 12:35, Tim Bunce wrote: There's actually an (almost completely undocumented) more_results() method that's meant for that kind of thing. I was rather surprised to find it wasn't documented as I'm pretty sure we thrashed out the semantics some time ago. [later] Wow, some time ago was

Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS

On Thu, Mar 15, 2012 at 10:33:43AM +, Martin J. Evans wrote: Argh, DBD::Oracle tracing is a mess wrt to this discussion: ocitrace.h: #define DBD_OCI_TRACEON (DBIS-debug = 6 || dbd_verbose=6) #define DBD_OCI_TRACEFP (DBILOGFP) #define