Skip site navigation (1) Skip section navigation (2)

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

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: explain analyze with 'rows' but not timing
Date: 2011-12-23 18:40:35
Message-ID: 4EF4CB23.7070601@fuzzy.cz (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Christopher BrowneDate: 2011-12-23 18:46:04
Subject: Re: Another hstore_type idea
Previous:From: Robert HaasDate: 2011-12-23 18:38:14
Subject: Re: Page Checksums + Double Writes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group