Re: Patch: add timing of buffer I/O requests

Greg Smith <greg(at)2ndQuadrant(dot)com> writes:
> On 11/28/2011 05:51 AM, Robert Haas wrote:
>> Assuming the feature is off by default (and I can't imagine we'd
>> consider anything else), I don't see why that should be cause for
>> concern. If the instrumentation creates too much system load, then
>> don't use it: simple as that.

> It's not quite that simple though. Releasing a performance measurement
> feature that itself can perform terribly under undocumented conditions
> has a wider downside than that.

Yeah, that's a good point, and the machines on which this would suck
are exactly the ones where EXPLAIN ANALYZE creates very large overhead.
We don't seem to see a lot of complaints about that anymore, but we do
still see some ... and yes, it's documented that EXPLAIN ANALYZE can add
significant overhead, but that doesn't stop the questions.

> Instrumentation that can itself become a performance problem is an
> advocacy problem waiting to happen. As I write this I'm picturing such
> an encounter resulting in an angry blog post, about how this proves
> PostgreSQL isn't usable for serious systems because someone sees massive
> overhead turning this on.

Of course, the rejoinder could be that if you see that, you're not
testing on serious hardware. But still, I take your point.

> Right now the primary exposure to this class
> of issue is EXPLAIN ANALYZE. When I was working on my book, I went out
> of my way to find a worst case for that[1],
> [1] (Dell Store 2 schema, query was "SELECT count(*) FROM customers;")

That's pretty meaningless without saying what sort of clock hardware
was on the machine...

regards, tom lane