Re: pg_stat_statements and planning time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_statements and planning time
Date: 2012-03-08 14:44:06
Message-ID: 10436.1331217846@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> On 8 March 2012 13:09, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-03-08 15:00:25 Re: pg_upgrade --logfile option documentation
Previous Message Dimitri Fontaine 2012-03-08 14:39:09 Re: Finer Extension dependencies