On Tue, Aug 28, 2012 at 10:43:07AM -0400, Robert Haas wrote:
> On Mon, Aug 27, 2012 at 11:13 PM, Greg Smith 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.
On Mon, Aug 27, 2012 at 11:13 PM, Greg Smith 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: http://www.enterprisedb.com
The Enterpri
On Tue, Aug 28, 2012 at 6:13 AM, Greg Smith 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
> I'd also guess "
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?
>
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, the<1 usec is where you want to
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
> On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian 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
On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian 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. first line
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
On Mon, Aug 27, 2012 at 12:39:02PM -0400, Robert Haas wrote:
> On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian 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 wrote:
> >> > FYI, I am planning to go ahead and package this
On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian 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 wrote:
>> > FYI, I am planning to go ahead and package this tool in /contrib for PG
>> > 9.3.
>>
>> Isn't this exactly what we a
On Mon, Aug 20, 2012 at 03:11:51PM -0400, Robert Haas wrote:
> On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian 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?
On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian 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
The Enterprise
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 (test_gett
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 with
On Wed, Dec 7, 2011 at 9:40 AM, Greg Smith 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, and a worst case
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 (cost=738.00..7
On Tue, Dec 6, 2011 at 9:58 PM, Greg Smith 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
> timing patch ena
Over in the "add timing of buffer I/O requests" thread I mentioned
having a system where EXPLAIN ANALYZE of a modest COUNT(*) takes 10X as
long as just executing the statement. Attached is a bit of SQL and a
script that runs it multiple times that demonstrate the problem on
systems that have i
18 matches
Mail list logo
