On Tue, Aug 28, 2012 at 6:13 AM, Greg Smith g...@2ndquadrant.com wrote:
After staring at all the examples I generated again, I think Bruce is right
that the newer format he's suggesting is better. I know I never thought
about whether reordering for easier interpretation made sense before, and
On Mon, Aug 27, 2012 at 11:13 PM, Greg Smith g...@2ndquadrant.com wrote:
After staring at all the examples I generated again, I think Bruce is right
that the newer format he's suggesting is better.
OK by me, then. If you're happy, I'm happy.
--
Robert Haas
EnterpriseDB:
On Tue, Aug 28, 2012 at 10:43:07AM -0400, Robert Haas wrote:
On Mon, Aug 27, 2012 at 11:13 PM, Greg Smith g...@2ndquadrant.com wrote:
After staring at all the examples I generated again, I think Bruce is right
that the newer format he's suggesting is better.
OK by me, then. If you're
On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Aug 20, 2012 at 03:11:51PM -0400, Robert Haas wrote:
On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian br...@momjian.us wrote:
FYI, I am planning to go ahead and package this tool in /contrib for PG
9.3.
Isn't
On Mon, Aug 27, 2012 at 12:39:02PM -0400, Robert Haas wrote:
On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Aug 20, 2012 at 03:11:51PM -0400, Robert Haas wrote:
On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian br...@momjian.us wrote:
FYI, I am planning to go
On Mon, Aug 27, 2012 at 01:18:51PM -0400, Bruce Momjian wrote:
This should make the output clearer to eyeball for problems --- a good
timing has a high percentage on the first line, rather than on the last
line.
I guess I'm not sure the output format is an improvement. I wouldn't
On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian br...@momjian.us wrote:
He wrote it that way to allow for simpler C code --- he could just start
from 31 and keeping skipping entries until he hit a non-zero.
My format makes it easy to see which line should have the majority of
the entries, e.g.
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian br...@momjian.us wrote:
He wrote it that way to allow for simpler C code --- he could just start
from 31 and keeping skipping entries until he hit a non-zero.
My format makes it
On 08/27/2012 06:20 PM, Bruce Momjian wrote:
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
I don't see why it's better for the first line to have a big number
than the last line. What difference does it make?
When you are looking at that output, the1 usec is where you want to
On Mon, Aug 27, 2012 at 11:13:00PM -0400, Greg Smith wrote:
On 08/27/2012 06:20 PM, Bruce Momjian wrote:
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
I don't see why it's better for the first line to have a big number
than the last line. What difference does it make?
When
On Mon, Aug 20, 2012 at 03:11:51PM -0400, Robert Haas wrote:
On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian br...@momjian.us wrote:
FYI, I am planning to go ahead and package this tool in /contrib for PG
9.3.
Isn't this exactly what we already did, in 9.2, in the form of
On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian br...@momjian.us wrote:
FYI, I am planning to go ahead and package this tool in /contrib for PG
9.3.
Isn't this exactly what we already did, in 9.2, in the form of
contrib/pg_test_timing?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
FYI, I am planning to go ahead and package this tool in /contrib for PG
9.3.
---
On Fri, Dec 9, 2011 at 08:26:12PM -0500, Greg Smith wrote:
On 12/09/2011 06:48 PM, Ants Aasma wrote:
The attached test program
On Wed, Dec 7, 2011 at 9:40 AM, Greg Smith g...@2ndquadrant.com wrote:
He estimated 22ns per gettimeofday on the system with fast timing
calls--presumably using TSC, and possibly faster than I saw because his
system had less cores than mine to worry about. He got 990 ns on his slower
system,
On 12/09/2011 06:48 PM, Ants Aasma wrote:
The attached test program (test_gettimeofday_monotonic) shows that one
test loop iteration takes 34ns with tsc and 1270ns with hpet.
This test program is great, I've wanted this exact sort of visibility
into this problem for years. I've toyed
On Tue, Dec 6, 2011 at 9:58 PM, Greg Smith g...@2ndquadrant.com wrote:
-If you have a system with a working TSC clock source (timing data is pulled
right from the CPU), timing overhead is reasonable enough that you might
turn it on even for things that happen frequently, such as the buffer I/O
On 12/06/2011 10:20 PM, Robert Haas wrote:
EXPLAIN ANALYZE is extremely
expensive mostly because it's timing entry and exit into every plan
node, and the way our executor works, those are very frequent
operations.
The plan for the query I was timing looks like this:
Aggregate
17 matches
Mail list logo
