On Mon, May 5, 2014 at 02:23:13PM -0700, Peter Geoghegan wrote:
> On Sun, May 4, 2014 at 6:49 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > + <listitem>
> > + <para>
> > + Have pg_stat_statements use a flat file for query text storage, allowing higher limits (Peter Geoghegan)
> > + </para>
> > +
> > + <para>
> > + Also add the ability to retrieve all pg_stat_statements information except the query text. This allows
programsto reuse the query
> > + text already retrieved by referencing queryid.
> > + </para>
> > + </listitem>
> >
> > This isn't an optional thing, is it?
>
> This is intended to be used by time-series monitoring tools that
> aggregate and graph pg_stat_statements data temporally. They usually
> won't need query texts, and so can only retrieve them lazily. The
> pg_stat_statements view presents exactly the same interface for ad-hoc
> querying, though.
>
> The point of the first item is that there is no longer *any*
> limitation on the size of stored query texts. They are no longer
> truncated to track_activity_query_size bytes. The shared memory
> overhead is also decreased substantially, allowing us to increase the
> default pg_stat_statements.max setting from 1,000 to 5,000, while
> still reducing the overall shared memory overhead (assuming a default
> track_activity_query_size). I think that the removal of the
> limitation, and the substantial lowering of the per-entry footprint
> should both be explicitly noted.
We rarely get into specific numers like this. It says "higher limit(s)" and
hopefully that is enough. If you want to create a documentation 'id' I
can like to that for the "higher limits" text.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +