Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally) - Mailing list pgsql-performance

From Tom Lane
Subject Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally)
Date
Msg-id 2555.1110213531@sss.pgh.pa.us
Whole thread Raw
In response to Re: [pgsql-hackers-win32] Help with tuning this query (with  (John A Meinel <john@arbash-meinel.com>)
Responses Re: [pgsql-hackers-win32] Help with tuning this query (with  (John A Meinel <john@arbash-meinel.com>)
List pgsql-performance
John A Meinel <john@arbash-meinel.com> writes:
>>> 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.

> Or we modify the win32 gettimeofday call to something like:

That's what Magnus was talking about, but it's really no good because
it would cause Postgres' now() function to fail to track post-boot-time
changes in the system date setting.  Which I think would rightly be
considered a bug.

The EXPLAIN ANALYZE instrumentation code will really be happier with a
straight time-since-bootup counter; by using gettimeofday, it is
vulnerable to giving wrong answers if someone changes the date setting
while the EXPLAIN is running.  But there is (AFAIK) no such call among
the portable Unix syscalls.  It seems reasonable to me to #ifdef that
code to make use of QueryPerformanceCounter on Windows.  This does not
mean we want to alter the behavior of gettimeofday() where it's being
used to find out the time of day.

            regards, tom lane

pgsql-performance by date:

Previous
From: John A Meinel
Date:
Subject: Re: [pgsql-hackers-win32] Help with tuning this query (with
Next
From: Hugo Ferreira
Date:
Subject: Help trying to tune query that executes 40x slower than in SqlServer