Re: pg_test_timing tool for EXPLAIN ANALYZE overhead

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, ants(dot)aasma(at)eesti(dot)ee
Subject: Re: pg_test_timing tool for EXPLAIN ANALYZE overhead
Date: 2012-03-27 20:25:42
Message-ID: CA+TgmoZsYG6ai4wZpc__VfvA1Rv=XsbXOHS9trRQnbTAJ9jwBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 22, 2012 at 6:53 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> A look back on this now that I'm done with it does raise one large question
> though.  I added some examples of how to measure timing overhead using psql.
>  While I like the broken down timing data that this utility provides, I'm
> not sure whether it's worth adding a contrib module just to get it now
> though.  Extension that's packaged on something like PGXN and easy to
> obtain?  Absolutely--but maybe that's a developer only level thing.  Maybe
> the only code worth distributing is the little SQL example of how to measure
> the overhead, along with some reference good/bad numbers.  That plus the
> intro to timer trivia could turn this into a documentation section only, no
> code change.  I've dreamed of running something like this on every system in
> the build farm.  Even if that's a valuable exercise, even then it may only
> be worth doing once, then reverting.

I had similar concerns, but decided to go ahead and commit this. It
doesn't relate particularly closely to the buffer I/O timings patch,
but I think it's worth having. We clearly need something that is
integrated with the PostgreSQL sources, because there is more than one
way to access timers, and this code will measure the overhead of doing
what PostgreSQL does, rather than the overhead of reading times in
some other way. Now, that doesn't preclude shipping this on PGXN, but
we've certainly got other things in contrib that are clearly a lot
less useful than this, and we've discussed before the folly of
shipping a database product without a full set of diagnostic tools.
Since this tool was developed to answer questions about whether
certain PostgreSQL options are safe to enable or whether they'll have
too much overhead, I think that's a sufficient reason to include it in
contrib, especially because you took the time to write some very good
documentation for it. I wonder whether we should perhaps move some of
this discussion of clock sources into the main documentation
somewhere, since it's not specifically related to this utility, but I
didn't try to do that for the moment and just left it as you had it.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-03-27 20:30:58 Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)
Previous Message Robert Haas 2012-03-27 20:17:18 pgsql: pg_test_timing utility, to measure clock monotonicity and timing