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

From Peter Geoghegan
Subject Re: pg_stat_statements and planning time
Date
Msg-id CAEYLb_WSr0eo+vOTcT7LikMfvc3p-x-BNRLFLj-tNJVuTGJBdA@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements and planning time  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 8 March 2012 14:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

To be clear, I don't see any reasons to not just have it within
EXPLAIN output under all circumstances.

pg_stat_statements will slow down query execution, but I see no reason
to force users to pay for something that they may well not want by not
including an 'off' switch for this additional instrumentation, given
that it doubles the number of gettimeofdays. I'm not particularly
concerned about platforms with slow gettimeofdays. I'm concerned with
keeping the overhead of running pg_stat_statements as low as possible
generally.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Collect frequency statistics for arrays
Next
From: Marti Raudsepp
Date:
Subject: [PATCH] Optimize IS DISTINCT FROM NULL => IS NOT NULL