On Mon, Jan 28, 2008 at 08:49:23PM +0000, Dean Rasheed wrote:
> > On Mon, Jan 28, 2008 at 07:55:53PM +0000, Dean Rasheed wrote:
> >>> Dean,
> >>> Maybe I missed something obvious here, but how does this patch handle
> >>> the situation where people have turned on INTEGER_DATETIMES?
> >>> Cheers,
> >>> David.
> >>> --
> >>> David Fetter http://fetter.org/
> >>> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> >>> Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
> >>> Remember to vote!
> >>> Consider donating to Postgres: http://www.postgresql.org/about/donate
> >> Sorry, I don't understand. I am new to this code, but I can't see
> >> how the INTEGER_DATETIMES flag will affect this code. I am using the
> >> macros and functions from instrument.h and explain.c for timing,
> >> which appear to use gettimeofday() or QueryPerformanceCounter(),
> >> coverting the result to a double to report the total time spent
> >> running the query.
> > It's the double part I don't quite get. Shouldn't that be an int64 in
> > the case of INTEGER_DATETIMES?
> > Cheers,
> > David.
> All the times are 64-bit integers (or at least structures with 2
> 32-bit integers in them) until the end, when the elapsed time is
> converted to a double so that the query runtime can be printed out
> in ms ("Query runtime: %.3f ms"). This is the same as EXPLAIN
> ANALYSE, except in that case it is the total runtime ("Total
> runtime: %.3f ms\n") that gets reported, including startup/shutdown
> trigger times.
Thanks for the explanation, and sorry for the noise :)
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
In response to
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2008-01-28 21:21:44|
|Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
|Previous:||From: Tom Lane||Date: 2008-01-28 21:04:38|
|Subject: Re: WIP: plpgsql source code obfuscation |