Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_test_timing utility, to measure clock monotonicity and timing cost.

  1. pgsql: pg_test_timing utility, to measure clock monotonicity and timing

    Robert Haas <rhaas@postgresql.org> — 2012-03-27T20:17:18Z

    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(-)

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

    Fujii Masao <masao.fujii@gmail.com> — 2012-03-28T02:10:46Z

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

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

    Robert Haas <robertmhaas@gmail.com> — 2012-03-28T12:19:37Z

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

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

    Marko Kreen <markokr@gmail.com> — 2012-03-28T12:46:26Z

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

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

    Marko Kreen <markokr@gmail.com> — 2012-03-28T12:51:35Z

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

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

    Robert Haas <robertmhaas@gmail.com> — 2012-03-28T12:57:42Z

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

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

    Marko Kreen <markokr@gmail.com> — 2012-03-28T13:13:16Z

    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@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

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

    Fujii Masao <masao.fujii@gmail.com> — 2012-03-28T14:43:56Z

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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-03-28T15:15:01Z

    Fujii Masao <masao.fujii@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

  10. Re: pgsql: pg_test_timing utility, to measure clock monotonicity and timing

    Alvaro Herrera <alvherre@commandprompt.com> — 2012-03-28T16:02:06Z

    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@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

  11. Re: pgsql: pg_test_timing utility, to measure clock monotonicity and timing

    Robert Haas <robertmhaas@gmail.com> — 2012-03-28T16:09:28Z

    On Wed, Mar 28, 2012 at 12:02 PM, Alvaro Herrera
<alvherre@commandprompt.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

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

    Fujii Masao <masao.fujii@gmail.com> — 2012-03-29T02:33:04Z

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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-03-29T02:45:00Z

    Fujii Masao <masao.fujii@gmail.com> writes:
> On Thu, Mar 29, 2012 at 12:15 AM, Tom Lane <tgl@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

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

    Robert Haas <robertmhaas@gmail.com> — 2012-03-30T12:19:17Z

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