Re: WIP: explain analyze with 'rows' but not timing

On 23.12.2011 16:14, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> One thing I'm wondering about is that the InstrumentOptions are not
>> exclusive - INSTRUMENT_TIMER means 'collect timing and row counts' while
>> INSTRUMENT_ROWS means 'collect row counts'. Wouldn't it be better to
>> redefine the INSTRUMENT_TIMER so that it collects just timing info. I.e.
>> to get the current behaviour, you'd have to do this
>
>> instrument_options |= (INSTRUMENT_TIMER | INSTRUMENT_ROWS)
>
>> It's quite trivial change in explain.c, the problem I have with that is
>> that it might break extensions.
>
> I'm not especially concerned by that angle --- we make bigger API
> changes all the time. But you could change the name, eg
>
> instrument_options |= (INSTRUMENT_TIMING | INSTRUMENT_ROWS)
>
> and then #define INSTRUMENT_TIMER as the OR of the two real bits
> for backward compatibility.

OK, that seems like a good solution. But is it worth the additional
complexity in explain.c?

The motivation for this patch was that collection timing data often
causes performance issues and in some cases it's not needed. But is this
true for row counts?

Are there machines where collecting row counts is above noise level?
I've never seen that, but that's not a proof of nonexistence.

If the overhead of this is negligible, then I could just hide the row
counts from the output.

Tomas