Re: pg_stat_statements and planning time - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stat_statements and planning time
Date
Msg-id 10436.1331217846@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stat_statements and planning time  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: pg_stat_statements and planning time
List pgsql-hackers
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 8 March 2012 13:09, Robert Haas <robertmhaas@gmail.com> wrote:
>> �Then again, considering that gettimeofday is kinda
>> expensive, I suppose that would have to be optional if we were to have
>> it at all.

> +1. I'm not opposed to having such a mechanism, but it really ought to
> impose exactly no overhead on the common case where we don't
> particularly care about plan time.

I thought the proposal was to add it to (1) pg_stat_statement and (2)
EXPLAIN, both of which are not in the normal code execution path.
pg_stat_statement is already a drag on a machine with slow gettimeofday,
but it's not clear why users of it would think that two gettimeofday's
per query are acceptable and four are not.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Finer Extension dependencies
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade --logfile option documentation