On Mon, May 5, 2014 at 02:23:13PM -0700, Peter Geoghegan wrote: > On Sun, May 4, 2014 at 6:49 AM, Andres Freund <and...@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 programs to 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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers