Horton

Re: pg_stat_statements and planning time

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-03-08T14:44:06Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow pg_stat_statements to track planning statistics.

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