Re: [Windows,PATCH] Use faster, higher precision timer API - Mailing list pgsql-hackers

From David Rowley
Subject Re: [Windows,PATCH] Use faster, higher precision timer API
Date
Msg-id CAApHDvpfsLNC8tDrP8HCabKHW8-HFvbwrw4geuE2hq-sTwwj6A@mail.gmail.com
Whole thread Raw
In response to Re: [Windows,PATCH] Use faster, higher precision timer API  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [Windows,PATCH] Use faster, higher precision timer API  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On 2 December 2014 at 15:36, Craig Ringer <craig@2ndquadrant.com> wrote:
On 12/01/2014 09:51 PM, Marco Nenciarini wrote:
> I think this is a leftover, as you don't use elog afterwards.

Good catch, fixed.


I've looked over this again and tested it on a windows 8.1 machine. I cannot find any problems

The only comments about the code I have would maybe be to use some constants like:

#define FILETIME_PER_SEC 10000000L
#define FILETIME_PER_USEC 10

I had to read the Microsoft documentation to see that "A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC)."


The attached patch gets rid of those magic numbers, and hopefully makes it a bit easier to see what's going on.

I agree with the lack of real need to log any sort of errors if init_win32_gettimeofday() gets any unexpected errors while trying to lookup GetSystemTimePreciseAsFileTime.

I'm marking this as ready for committer. It seems worth going in just for the performance improvement alone, never mind the increased clock accuracy.

I'll leave it up to the committer to decide if it's better with or without the attached patch.

Regards

David Rowley
Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: libpq pipelining
Next
From: Bruce Momjian
Date:
Subject: Re: Testing DDL deparsing support