"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2006-12-15 at 09:56 -0500, Tom Lane wrote:
>> The fundamental problem with it was the assumption that different
>> executions of a plan node will have the same timing. That's not true,
>> in fact not even approximately true.
> It doesn't make s
On Fri, 2006-12-15 at 10:57 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs:
> >> Until we work out a better solution we can fix this in two ways:
> >>
> >> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] .
At 10:45 AM 12/15/2006, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
> There are various attempts at providing better timing infrastructure at low
> overhead but I'm not sure what's out there currently. I expect to
do this what
> we'll have to do is invent a pg_* abstraction that ha
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > There are various attempts at providing better timing infrastructure at low
> > overhead but I'm not sure what's out there currently. I expect to do this
> > what
> > we'll have to do is invent a pg_* abstraction
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs:
>> Until we work out a better solution we can fix this in two ways:
>>
>> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
>> 2. enable_analyze_timer = off | on (default) (USERSET)
On Fri, Dec 15, 2006 at 09:56:57AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Fri, Dec 15, 2006 at 12:20:46PM +, Simon Riggs wrote:
> >> Maybe sampling every 10 rows will bring things down to an acceptable
> >> level (after the first N). You tried less than 10 didn't you?
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> There are various attempts at providing better timing infrastructure at low
> overhead but I'm not sure what's out there currently. I expect to do this what
> we'll have to do is invent a pg_* abstraction that has various implementations
> on different ar
Martijn van Oosterhout writes:
> On Fri, Dec 15, 2006 at 12:20:46PM +, Simon Riggs wrote:
>> Maybe sampling every 10 rows will bring things down to an acceptable
>> level (after the first N). You tried less than 10 didn't you?
> Yeah, it reduced the number of calls as the count got larger. It
Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs:
> Until we work out a better solution we can fix this in two ways:
>
> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
>
> 2. enable_analyze_timer = off | on (default) (USERSET)
The second one is enough in my mind.
--
Peter E
* Simon Riggs:
>> I think the best option is setitimer(), but it's not POSIX so
>> platform support is going to be patchy.
>
> Don't understand that. I thought that was to do with alarms and
> signals.
You could use it for sampling. Every few milliseconds, you record
which code is executing (pos
On Fri, Dec 15, 2006 at 12:20:46PM +, Simon Riggs wrote:
> > I
> > wrote a patch that tried statistical sampling, but the figures were too
> > far off for people's liking.
>
> Well, I like your ideas, so if you have any more...
>
> Maybe sampling every 10 rows will bring things down to an acc
On Fri, Dec 15, 2006 at 12:15:59PM +, Gregory Stark wrote:
> There are various attempts at providing better timing infrastructure at low
> overhead but I'm not sure what's out there currently. I expect to do this what
> we'll have to do is invent a pg_* abstraction that has various implementati
On Fri, 2006-12-15 at 11:50 +0100, Martijn van Oosterhout wrote:
> On Fri, Dec 15, 2006 at 10:28:08AM +, Simon Riggs wrote:
> > Until we work out a better solution we can fix this in two ways:
> >
> > 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
> >
> > 2. enable_analyze_time
"Martijn van Oosterhout" writes:
> BTW, doing gettimeofday() without kernel entry is not really possible.
That's too strong a conclusion. Doing gettimeofday() without some help from
the kernel isn't possible but it isn't necessary to enter the kernel for each
call.
There are various attempts at
Hi list,
Le vendredi 15 décembre 2006 11:50, Martijn van Oosterhout a écrit :
> BTW, doing gettimeofday() without kernel entry is not really possible.
> You could use the cycle counter but it has the problem that if you have
> multiple CPUs you need to calibrate the result. If the CPU goes to
> sl
On Fri, Dec 15, 2006 at 10:28:08AM +, Simon Riggs wrote:
> Until we work out a better solution we can fix this in two ways:
>
> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
>
> 2. enable_analyze_timer = off | on (default) (USERSET)
What exactly would this do? Only count actu
On Thu, 2006-12-14 at 19:05 -0500, Tom Lane wrote:
> "Kelly Burkhart" <[EMAIL PROTECTED]> writes:
> > I hope this isn't a "crummy mainboard" but I can't seem to affect
> > things by changing clock source (kernel 2.6.16 SLES10). I tried
> > kernel command option clock=XXX where XXX in
> > (cyclone,
17 matches
Mail list logo
