[HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-30 Thread Robert Haas
On Wed, Mar 28, 2012 at 10:43 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Wed, Mar 28, 2012 at 9:19 PM, Robert Haas robertmh...@gmail.com wrote:
 On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
 On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas rh...@postgresql.org wrote:
 pg_test_timing utility, to measure clock monotonicity and timing cost.

 When I compiled this, I got a compiler warning. Attached patch
 silences the warning.

 Unfortunately, that *produces* a warning on my machine.  Normally, I
 think we handle this using INT64_FORMAT, but the fact that it's %10ld
 here and not just %lld makes that awkward.  I guess we maybe need to
 insert some kludgy workaround here - write it into a separate buffer,
 and then blank-pad it, or something like that.

 This seems a simplest workaround. How about attached patch?

Thanks, committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Robert Haas
On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
 On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas rh...@postgresql.org wrote:
 pg_test_timing utility, to measure clock monotonicity and timing cost.

 When I compiled this, I got a compiler warning. Attached patch
 silences the warning.

Unfortunately, that *produces* a warning on my machine.  Normally, I
think we handle this using INT64_FORMAT, but the fact that it's %10ld
here and not just %lld makes that awkward.  I guess we maybe need to
insert some kludgy workaround here - write it into a separate buffer,
and then blank-pad it, or something like that.

 Also I found one trivial problem in the doc of pg_test_timing. The
 patch fixes that.

Thanks, committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Marko Kreen
On Wed, Mar 28, 2012 at 08:19:37AM -0400, Robert Haas wrote:
 On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
  On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas rh...@postgresql.org wrote:
  pg_test_timing utility, to measure clock monotonicity and timing cost.
 
  When I compiled this, I got a compiler warning. Attached patch
  silences the warning.
 
 Unfortunately, that *produces* a warning on my machine.  Normally, I
 think we handle this using INT64_FORMAT, but the fact that it's %10ld
 here and not just %lld makes that awkward.  I guess we maybe need to
 insert some kludgy workaround here - write it into a separate buffer,
 and then blank-pad it, or something like that.

How about:  .. %10 INT64_FORMAT  ..  ?

-- 
marko


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Marko Kreen
On Wed, Mar 28, 2012 at 03:46:26PM +0300, Marko Kreen wrote:
 On Wed, Mar 28, 2012 at 08:19:37AM -0400, Robert Haas wrote:
  On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
   On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas rh...@postgresql.org wrote:
   pg_test_timing utility, to measure clock monotonicity and timing cost.
  
   When I compiled this, I got a compiler warning. Attached patch
   silences the warning.
  
  Unfortunately, that *produces* a warning on my machine.  Normally, I
  think we handle this using INT64_FORMAT, but the fact that it's %10ld
  here and not just %lld makes that awkward.  I guess we maybe need to
  insert some kludgy workaround here - write it into a separate buffer,
  and then blank-pad it, or something like that.
 
 How about:  .. %10 INT64_FORMAT  ..  ?

Well, it won't work because unlike inttypes.h, Postgres *_FORMAT
includes '%' in it.

I guess that why inttypes.h does not do it...

-- 
marko


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Robert Haas
On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen mark...@gmail.com wrote:
 How about:  .. %10 INT64_FORMAT  ..  ?

 Well, it won't work because unlike inttypes.h, Postgres *_FORMAT
 includes '%' in it.

 I guess that why inttypes.h does not do it...

Hmm, I guess we could change that, but it would create a hazard for
thirty-party code that wants to be cross-version, and for
back-patching.  We could work around that by doing something more
complex, like creating additional symbols, but I'm thinking it ain't
worth it just for this.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Marko Kreen
On Wed, Mar 28, 2012 at 08:57:42AM -0400, Robert Haas wrote:
 On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen mark...@gmail.com wrote:
  How about:  .. %10 INT64_FORMAT  ..  ?
 
  Well, it won't work because unlike inttypes.h, Postgres *_FORMAT
  includes '%' in it.
 
  I guess that why inttypes.h does not do it...
 
 Hmm, I guess we could change that, but it would create a hazard for
 thirty-party code that wants to be cross-version, and for
 back-patching.  We could work around that by doing something more
 complex, like creating additional symbols, but I'm thinking it ain't
 worth it just for this.

Changing existing definition is bad idea indeed.

And long-term path should be to move to standard int types,
so another custom definition seems counter-productive.
(OTOH, the 2 int64 _FORMATs are the only formats we maintain.)

In this case the simple approach would be to use 'long long':

  .. %10lld .., (long long)(..)

At least ecpg code uses it freely, and nobody has complained, so I guess
we don't have any platforms that do not have it.

-- 
marko


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Fujii Masao
On Wed, Mar 28, 2012 at 9:19 PM, Robert Haas robertmh...@gmail.com wrote:
 On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
 On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas rh...@postgresql.org wrote:
 pg_test_timing utility, to measure clock monotonicity and timing cost.

 When I compiled this, I got a compiler warning. Attached patch
 silences the warning.

 Unfortunately, that *produces* a warning on my machine.  Normally, I
 think we handle this using INT64_FORMAT, but the fact that it's %10ld
 here and not just %lld makes that awkward.  I guess we maybe need to
 insert some kludgy workaround here - write it into a separate buffer,
 and then blank-pad it, or something like that.

This seems a simplest workaround. How about attached patch?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgtesttiming_int64format.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Tom Lane
Fujii Masao masao.fu...@gmail.com writes:
 This seems a simplest workaround. How about attached patch?

I think you need to tweak that to get the number to be right-justified
not left-justified.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Fujii Masao
On Thu, Mar 29, 2012 at 12:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Fujii Masao masao.fu...@gmail.com writes:
 This seems a simplest workaround. How about attached patch?

 I think you need to tweak that to get the number to be right-justified
 not left-justified.

Unless I'm missing something, I did that because the patch uses %10s
not %-10s. No?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-28 Thread Tom Lane
Fujii Masao masao.fu...@gmail.com writes:
 On Thu, Mar 29, 2012 at 12:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 I think you need to tweak that to get the number to be right-justified
 not left-justified.

 Unless I'm missing something, I did that because the patch uses %10s
 not %-10s. No?

Oh, you're right, I was misremembering which direction that went.
Sorry for the noise.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

2012-03-27 Thread Fujii Masao
On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas rh...@postgresql.org wrote:
 pg_test_timing utility, to measure clock monotonicity and timing cost.

When I compiled this, I got a compiler warning. Attached patch
silences the warning.

Also I found one trivial problem in the doc of pg_test_timing. The
patch fixes that.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
*** a/contrib/pg_test_timing/pg_test_timing.c
--- b/contrib/pg_test_timing/pg_test_timing.c
***
*** 155,161  test_timing(int32 duration)
  if (found || histogram[i])
  {
  found = 1;
! printf(%9ld: %10ld %8.5f%%\n, 1l  i, histogram[i],
  (double) histogram[i] * 100 / loop_count);
  }
  }
--- 155,161 
  if (found || histogram[i])
  {
  found = 1;
! printf(%9ld: %10lld %8.5f%%\n, 1l  i, histogram[i],
  (double) histogram[i] * 100 / loop_count);
  }
  }
*** a/doc/src/sgml/pgtesttiming.sgml
--- b/doc/src/sgml/pgtesttiming.sgml
***
*** 28,35  pg_test_timing [options]
  variablelist
  
   varlistentry
!   termoption-d/option/term
!   termoption--duration/option/term
listitem
 para
  Specifies the test duration, in seconds. Longer durations
--- 28,35 
  variablelist
  
   varlistentry
!   termoption-d replaceable class=parameterduration/replaceable/option/term
!   termoption--duration=replaceable class=parameterduration/replaceable/option/term
listitem
 para
  Specifies the test duration, in seconds. Longer durations

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers