Обсуждение: Re: [pgsql-hackers-win32] explain analyze timings

Поиск
Список
Период
Сортировка

Re: [pgsql-hackers-win32] explain analyze timings

От
"Magnus Hagander"
Дата:
>> There is. I beleive QueryPerformanceCounter has sub-mirosecond
>> resolution.
>
>> Can we just replace gettimeofday() with a version that's basically:
>
>No, because it's also used for actual time-of-day calls.  It'd be
>necessary to hack executor/instrument.c in particular.

Here's a patch that does just this.

On my system, the counter resolution is 3192090000 ticks per second
(Intel Xeon CPU). On a AMD Athlon XP system, it's 3579545 ticks per
second (a lot less, but still way way way better than gettimeofday has
on win32).

I also hacked commands/explain.c to get the total runtime of the query
correct.

//Magnus

Вложения

Re: [pgsql-hackers-win32] explain analyze timings

От
Simon Riggs
Дата:
On Sun, 2005-03-20 at 14:42 +0100, Magnus Hagander wrote:
> >> There is. I beleive QueryPerformanceCounter has sub-mirosecond
> >> resolution.
> >
> >> Can we just replace gettimeofday() with a version that's basically:
> >
> >No, because it's also used for actual time-of-day calls.  It'd be
> >necessary to hack executor/instrument.c in particular.
>
> Here's a patch that does just this.
>
> On my system, the counter resolution is 3192090000 ticks per second
> (Intel Xeon CPU). On a AMD Athlon XP system, it's 3579545 ticks per
> second (a lot less, but still way way way better than gettimeofday has
> on win32).

Is this just a Win32 hack?

I've been looking for a sub-millisecond counter on other OS for a while
now...anybody know of any port specific counters elsewhere?

Thanks,

Best Regards, Simon Riggs


Re: [pgsql-hackers-win32] explain analyze timings

От
Tom Lane
Дата:
"Magnus Hagander" <mha@sollentuna.net> writes:
> Here's a patch that does just this.

This seems about the ugliest and most intrusive way you could have
done it :-(.  A judicious typedef and macro or two could eliminate
most of the #ifdefs and code duplication, thereby preserving
readability...

            regards, tom lane