On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote:
It would be much easier for Tim to do it from the inside than any of us
doing the overloading hacking, but that's up to Tim to decide when if ever
this should go in :)
Things are changing for the better workwise now and I hope to
On Fri, 1 Dec 2000, Tim Bunce wrote:
On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote:
It would be much easier for Tim to do it from the inside than any of us
doing the overloading hacking, but that's up to Tim to decide when if ever
this should go in :)
Things are changing
On Fri, Dec 01, 2000 at 09:48:34AM +, Matt Sergeant wrote:
On Fri, 1 Dec 2000, Tim Bunce wrote:
On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote:
It would be much easier for Tim to do it from the inside than any of us
doing the overloading hacking, but that's up to
Tim Bunce wrote:
On Fri, Dec 01, 2000 at 09:48:34AM +, Matt Sergeant wrote:
On Fri, 1 Dec 2000, Tim Bunce wrote:
On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote:
It would be much easier for Tim to do it from the inside than any of us
doing the overloading
On Fri, Dec 01, 2000 at 12:23:26PM +, Greg Cope wrote:
Tim Bunce wrote:
Although a bit OT, but I am sure everyone is interested, what changes
are you planning for DBI ?
There's a ToDo file in the dist. I've probably a few others rattling
around in my head.
Tim.
An:mod_perl list [EMAIL PROTECTED]
Betreff: RFC: DBI::Prof
Nachrichtentext:
I have a huge project with lots of tables, and the performance wasn't that
well. So I've started to review the tables definitions and have found that
some indices were missing. I was sick from doing the tracing of all
any of us
doing the overloading hacking, but that's up to Tim to decide when if ever
this should go in :)
Michael Jacob
Datum: 28.11.2000 21:12
An:mod_perl list [EMAIL PROTECTED]
Betreff: RFC: DBI::Prof
Nachrichtentext:
I have a huge project with lots
I have a huge project with lots of tables, and the performance wasn't that
well. So I've started to review the tables definitions and have found that
some indices were missing. I was sick from doing the tracing of all
possible SQL calls manually, so I wrote this simple profiler. Take a look
and
On Tue, 28 Nov 2000, Stas Bekman wrote:
I have a huge project with lots of tables, and the performance wasn't that
well. So I've started to review the tables definitions and have found that
some indices were missing. I was sick from doing the tracing of all
possible SQL calls manually, so I
On Tue, 28 Nov 2000, Stas wrote:
possible SQL calls manually, so I wrote this simple profiler. Take a look
and tell me if you think it worths releasing on CPAN...
Definitely release it! It is a very elegant solution to a problem that I'm
guessing many of us have dealt with. I've always
On Tue, 28 Nov 2000, Stas Bekman wrote:
I have a huge project with lots of tables, and the performance wasn't that
well. So I've started to review the tables definitions and have found that
some indices were missing. I was sick from doing the tracing of all
possible SQL calls manually,
On Tue, 28 Nov 2000, Stas Bekman wrote:
Or is there any reason for not using DBI::?
Tim mandates it. DBI:: is reserved for DBI only. DBD::* is reserved for
DBD drivers only, anything else goes in DBIx.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML
It would be nice if Tim Bunce simply added it as a parameter
to DBI's existing methods. Why not ask him?
Fabrice
Aaron Ross wrote:
On Tue, 28 Nov 2000, Stas wrote:
possible SQL calls manually, so I wrote this simple profiler. Take a look
and tell me if you think it worths releasing on
On Wed, 29 Nov 2000, Fabrice Scemama wrote:
It would be nice if Tim Bunce simply added it as a parameter
to DBI's existing methods. Why not ask him?
I think most people would prefer to see it as a separate module. Generally
people do their query optimisations outside of DBI (and Perl), using
On Tue, 28 Nov 2000, Stas Bekman wrote:
Looks like it does pretty much the same but returns too much info, which
makes it quite hard to use when you have 100+ queries in some requests :)
I suspect it would be pretty easy to add in a threshold like the one in
your module.
And fetch()es are
On Tue, 28 Nov 2000, Matt Sergeant wrote:
On Wed, 29 Nov 2000, Fabrice Scemama wrote:
It would be nice if Tim Bunce simply added it as a parameter
to DBI's existing methods. Why not ask him?
I think most people would prefer to see it as a separate module. Generally
people do their
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
On Tue, 28 Nov 2000, Stas Bekman wrote:
And fetch()es are quite irrelevant for performance
improvements since they
never change unless you compare TCP/IP vs UNIX sockets or one driver
against the other.
I find the fetch information
17 matches
Mail list logo
