Re: URGENT HELP about 'duration' stats - Mailing list pgsql-hackers

From Camilo Porto
Subject Re: URGENT HELP about 'duration' stats
Date
Msg-id BLU111-W4F245D9D14469DA3F8AA8BC970@phx.gbl
Whole thread Raw
In response to Re: URGENT HELP about 'duration' stats  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: URGENT HELP about 'duration' stats
List pgsql-hackers


[Camilo Porto]



> To: camiloporto@hotmail.com
> CC: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] URGENT HELP about 'duration' stats
> Date: Fri, 26 Oct 2007 23:06:22 -0400
> From: tgl@sss.pgh.pa.us
>
> Camilo Porto <camiloporto@hotmail.com> writes:
> > The problem I have encountered is that the sum of executor's
> > duration time is, *sometimes*, bigger than the total time interval in
> > which the statements had been executed!! And this makes no sense!
>
> Umm ... why not? If you have, say, two queries executing in parallel
> for 1 second, they'll each report a duration: of 1 second, thus summing
> to 2 seconds, but the elapsed time was only 1 second.
>
> If you don't see that always, then your benchmark program isn't trying
> very hard to run more than one query in parallel ...

This really make sense, but let me add some questions:

The parallelism happens even if my PC has only one processor?
Each query is executed in a separeted Thread?
I am simulating only 1 client with the Benchmark. Can 1 Client submit parallel queries, in single-processor enviroment?

Many Thanks
>
> regards, tom lane


Veja mapas e encontre as melhores rotas para fugir do trânsito com o Live Search Maps! Experimente já!

pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: Proposal: real procedures again (8.4)
Next
From: Tom Lane
Date:
Subject: Re: Proposal: real procedures again (8.4)