From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: That EXPLAIN ANALYZE patch still needs work |
Date: | 2006-06-06 21:17:19 |
Message-ID: | 23337.1149628639@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> If that's the case, then maybe a more sopdisticated method of measuring
> the overhead would work.
I think you missed the point: the time spent in gettimeofday() itself
is not the major overhead of EXPLAIN ANALYZE. At least it appears that
this is the case on my machine.
I'm thinking that interrupt-driven sampling might work OK though.
My previous worries were based on trying to use the ITIMER_PROF
timer, which might not be portable and would conflict with gprof
anyway. But EXPLAIN ANALYZE has always been interested in real time
rather than CPU time, so the correct interrupt to use is ITIMER_REAL.
That means we only have to share with our own existing usages of that
interrupt, which turns it from a portability issue into just a Small
Matter Of Programming.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zoltan Boszormenyi | 2006-06-06 21:19:08 | SERIAL problems? |
Previous Message | Jim C. Nasby | 2006-06-06 21:05:20 | Re: That EXPLAIN ANALYZE patch still needs work |