On Mon, Jul 2, 2007, "Jim C. Nasby" <[EMAIL PROTECTED]> said:
> On Thu, Jun 28, 2007 at 01:35:22AM -0700, Aaron Stone wrote: >> On Thu, 2007-06-28 at 10:02 +0200, Marc Dirix wrote: >> > > >> > > Right, and mysql can, too. But looking at eg. the "slow squirrelmail" >> > > thread on the dbmail list right now, if dbmail itsself provided timing >> > > along with all the other level 5 info, there would be no need to be >> > > requesting that from the original poster. That's a somewhat common = > =20 >> > > info >> > > request, so would save time debuggging things. It wouldn't slow =20 >> > > things >> > > too much (primarily the extra log message) .. and as you mentioned, = > =20 >> > > level >> > > is slow, it's only for debugging problems, not real use. >> > > >> >=20 >> > As most do these sort of debugging on the production system, I would = > =20 >> > say every performance hit >> > has to be taken with care. I would not like to put anymore strain on = > =20 >> > the users then necessary when >> > already debugging a "slow" problem. >>=20 >> How expensive can doing this ourselves this be? Two calls to time(2), >> subtract, compare with some threshold value, log if it exceeds that. >> Seems like a great deal because we can log slow queries at a higher >> level, making it less expensive to debug problems like these. > > PostgreSQL uses gettimeofday() to handle a bunch of stuff, and we've > found that in some environments it's got a pretty substantial overhead. > For example, EXPLAIN ANALYZE (which makes heavy use of gettimeofday()) > can sometimes take 30% longer than running the query by itself. So I > wouldn't just hand-waive this away. OTOH, if each time you run it you're > sending a command across the wire to a database server... At least on HP-UX on Itanium, gettimeofday() is 6x the cost of time(NULL). I wonder if other systems have similar characteristics. I could not find any other microsecond / clock cycle breakdowns, however. I'd love to cite a few sources, though! http://h21007.www2.hp.com/portal/download/files/unprot/hpux/HowToTellTheTime.pdf Anyways, I implemented the code with time(NULL) because I don't care about queries that take 5ms vs. 50ms right now. I want to know what's sometimes causing people to twiddle their thumbs for many seconds. > BTW, for performance-conscious folks, converting raw query calls into > functions/procedures could produce a good gain, *especially* in cases > where you're sending multiple commands to do something. At the very least we want to use prepared statement in the future. There's a wiki page on the subject called safer_sql. Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
