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

pg_test_timing utility, to measure clock monotonicity and timing cost.

Ants Aasma, Greg Smith

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/cee523867db29c0bfc5de7ec638ce0a4ad9b3817

Modified Files
--------------
contrib/Makefile | 1 +
contrib/pg_test_timing/.gitignore | 1 +
contrib/pg_test_timing/Makefile | 18 ++
contrib/pg_test_timing/pg_test_timing.c | 162 +++++++++++++++++++
doc/src/sgml/config.sgml | 4 +-
doc/src/sgml/contrib.sgml | 1 +
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/perform.sgml | 4 +-
doc/src/sgml/pgtesttiming.sgml | 261 +++++++++++++++++++++++++++++++
9 files changed, 451 insertions(+), 2 deletions(-)

On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas <rhaas(at)postgresql(dot)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

On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas <rhaas(at)postgresql(dot)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

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(dot)fujii(at)gmail(dot)com> wrote:
> > On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas <rhaas(at)postgresql(dot)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

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(dot)fujii(at)gmail(dot)com> wrote:
> > > On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas <rhaas(at)postgresql(dot)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

On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen <markokr(at)gmail(dot)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

On Wed, Mar 28, 2012 at 08:57:42AM -0400, Robert Haas wrote:
> On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen <markokr(at)gmail(dot)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

On Wed, Mar 28, 2012 at 9:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas <rhaas(at)postgresql(dot)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

Fujii Masao <masao(dot)fujii(at)gmail(dot)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

Excerpts from Robert Haas's message of mar mar 27 17:17:18 -0300 2012:
> pg_test_timing utility, to measure clock monotonicity and timing cost.
>
> Ants Aasma, Greg Smith

Did anyone notice that this broke several win32 buildfarm members? It
seems to be missing snprintf and other stuff. I guess it needs pgport.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Wed, Mar 28, 2012 at 12:02 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Robert Haas's message of mar mar 27 17:17:18 -0300 2012:
>> pg_test_timing utility, to measure clock monotonicity and timing cost.
>>
>> Ants Aasma, Greg Smith
>
> Did anyone notice that this broke several win32 buildfarm members?  It
> seems to be missing snprintf and other stuff.  I guess it needs pgport.

I did not. I'll take a look.

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

On Thu, Mar 29, 2012 at 12:15 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)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

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Thu, Mar 29, 2012 at 12:15 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

On Wed, Mar 28, 2012 at 10:43 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Mar 28, 2012 at 9:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas <rhaas(at)postgresql(dot)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