summaryrefslogtreecommitdiff
path: root/src/include/pgstat.h
Commit message (Collapse)AuthorAgeFilesLines
* Save pg_stat_statements statistics file into $PGDATA/pg_stat directory at ↵Fujii Masao2014-06-041-0/+8
| | | | | | | | | | | | | shutdown. 187492b6c2e8cafc5b39063ca3b67846e8155d24 changed pgstat.c so that the stats files were saved into $PGDATA/pg_stat directory when the server was shutdowned. But it accidentally forgot to change the location of pg_stat_statements permanent stats file. This commit fixes pg_stat_statements so that its stats file is also saved into $PGDATA/pg_stat at shutdown. Since this fix changes the file layout, we don't back-patch it to 9.3 where this oversight was introduced.
* pgindent run for 9.4Bruce Momjian2014-05-061-11/+13
| | | | | This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
* Fix some compiler warnings that clang emits with -pedantic.Robert Haas2014-04-041-1/+1
| | | | Andres Freund
* Show xid and xmin in pg_stat_activity and pg_stat_replication.Robert Haas2014-02-251-0/+29
| | | | | Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
* Make pg_basebackup skip temporary statistics files.Fujii Masao2014-02-031-0/+3
| | | | | | | | The temporary statistics files don't need to be included in the backup because they are always reset at the beginning of the archive recovery. This patch changes pg_basebackup so that it skips all files located in $PGDATA/pg_stat_tmp or the directory specified by stats_temp_directory parameter.
* Add pg_stat_archiver statistics view.Fujii Masao2014-01-291-1/+33
| | | | | | This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
* Fix VACUUM's reporting of dead-tuple counts to the stats collector.Tom Lane2014-01-181-2/+3
| | | | | | | | | | | | | | | | | Historically, VACUUM has just reported its new_rel_tuples estimate (the same thing it puts into pg_class.reltuples) to the stats collector. That number counts both live and dead-but-not-yet-reclaimable tuples. This behavior may once have been right, but modern versions of the pgstats code track live and dead tuple counts separately, so putting the total into n_live_tuples and zero into n_dead_tuples is surely pretty bogus. Fix it to report live and dead tuple counts separately. This doesn't really do much for situations where updating transactions commit concurrently with a VACUUM scan (possibly causing double-counting or omission of the tuples they add or delete); but it's clearly an improvement over what we were doing before. Hari Babu, reviewed by Amit Kapila
* Update copyright for 2014Bruce Momjian2014-01-071-1/+1
| | | | | Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
* Fix calculation of maximum statistics-message size.Tom Lane2014-01-021-4/+6
| | | | | | | | | | | | | | | | | | The PGSTAT_NUM_TABENTRIES macro should have been updated when new fields were added to struct PgStat_MsgTabstat in commit 644828908, but it wasn't. Fix that. Also, add a static assertion that we didn't overrun the intended size limit on stats messages. This will not necessarily catch every mistake in computing the maximum array size for stats messages, but it will catch ones that have practical consequences. (The assertion in fact doesn't complain about the aforementioned error in PGSTAT_NUM_TABENTRIES, because that was not big enough to cause the array length to increase.) No back-patch, as there's no actual bug in existing releases; this is just in the nature of future-proofing. Mark Dilger and Tom Lane
* Split pgstat file in smaller piecesAlvaro Herrera2013-02-181-1/+4
| | | | | | | | | | | | | | | | We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
* Update copyrights for 2013Bruce Momjian2013-01-011-1/+1
| | | | | Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
* Unify calling conventions for postgres/postmaster sub-main functionsPeter Eisentraut2012-06-251-1/+1
| | | | | | | | | | | There was a wild mix of calling conventions: Some were declared to return void and didn't return, some returned an int exit code, some claimed to return an exit code, which the callers checked, but actually never returned, and so on. Now all of these functions are declared to return void and decorated with attribute noreturn and don't return. That's easiest, and most code already worked that way.
* Fix stats collector to recover nicely when system clock goes backwards.Tom Lane2012-06-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
* Run pgindent on 9.2 source tree in preparation for first 9.3Bruce Momjian2012-06-101-9/+10
| | | | commit-fest.
* Converge all SQL-level statistics timing values to float8 milliseconds.Tom Lane2012-04-301-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
* Rename I/O timing statistics columns to blk_read_time and blk_write_time.Tom Lane2012-04-291-8/+8
| | | | | This seems more consistent with the pre-existing choices for names of other statistics columns. Rename assorted internal identifiers to match.
* Publish checkpoint timing information to pg_stat_bgwriter.Robert Haas2012-04-051-0/+4
| | | | Greg Smith, Peter Geoghegan, and Robert Haas
* Expose track_iotiming data via the statistics collector.Robert Haas2012-04-051-0/+14
| | | | | | Ants Aasma's original patch to add timing information for buffer I/O requests exposed this data at the relation level, which was judged too costly. I've here exposed it at the database level instead.
* Add deadlock counter to pg_stat_databaseMagnus Hagander2012-01-261-2/+17
| | | | | | | Adds a counter that tracks number of deadlocks that occurred in each database to pg_stat_database. Magnus Hagander, reviewed by Jaime Casanova
* Track temporary file count and size in pg_stat_databaseMagnus Hagander2012-01-261-1/+18
| | | | | | | | Add counters for number and size of temporary files used for spill-to-disk queries for each database to the pg_stat_database view. Tomas Vondra, review by Magnus Hagander
* Separate state from query string in pg_stat_activityMagnus Hagander2012-01-191-1/+20
| | | | | | | | | | | | | | | | This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
* Update copyright notices for year 2012.Bruce Momjian2012-01-011-1/+1
|
* In COPY, insert tuples to the heap in batches.Heikki Linnakangas2011-11-091-1/+1
| | | | | | | This greatly reduces the WAL volume, especially when the table is narrow. The overhead of locking the heap page is also reduced. Reduced WAL traffic also makes it scale a lot better, if you run multiple COPY processes at the same time.
* Code review for pgstat_get_crashed_backend_activity patch.Tom Lane2011-10-211-1/+1
| | | | | | | Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
* Try to log current the query string when a backend crashes.Robert Haas2011-10-211-0/+2
| | | | | | | | | | | | | | | | To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
* Move Timestamp/Interval typedefs and basic macros into datatype/timestamp.h.Tom Lane2011-09-091-1/+2
| | | | | | | | | | | As per my recent proposal, this refactors things so that these typedefs and macros are available in a header that can be included in frontend-ish code. I also changed various headers that were undesirably including utils/timestamp.h to include datatype/timestamp.h instead. Unsurprisingly, this showed that half the system was getting utils/timestamp.h by way of xlog.h. No actual code changes here, just header refactoring.
* Fix VACUUM so that it always updates pg_class.reltuples/relpages.Tom Lane2011-05-301-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we added the ability for vacuum to skip heap pages by consulting the visibility map, we made it just not update the reltuples/relpages statistics if it skipped any pages. But this could leave us with extremely out-of-date stats for a table that contains any unchanging areas, especially for TOAST tables which never get processed by ANALYZE. In particular this could result in autovacuum making poor decisions about when to process the table, as in recent report from Florian Helmberger. And in general it's a bad idea to not update the stats at all. Instead, use the previous values of reltuples/relpages as an estimate of the tuple density in unvisited pages. This approach results in a "moving average" estimate of reltuples, which should converge to the correct value over multiple VACUUM and ANALYZE cycles even when individual measurements aren't very good. This new method for updating reltuples is used by both VACUUM and ANALYZE, with the result that we no longer need the grotty interconnections that caused ANALYZE to not update the stats depending on what had happened in the parent VACUUM command. Also, fix the logic for skipping all-visible pages during VACUUM so that it looks ahead rather than behind to decide what to do, as per a suggestion from Greg Stark. This eliminates useless scanning of all-visible pages at the start of the relation or just after a not-all-visible page. In particular, the first few pages of the relation will not be invariably included in the scanned pages, which seems to help in not overweighting them in the reltuples estimate. Back-patch to 8.4, where the visibility map was introduced.
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-101-2/+2
|
* Add client_hostname field to pg_stat_activity.Robert Haas2011-02-171-0/+1
| | | | Peter Eisentraut, reviewed by Steve Singer, Alvaro Herrera, and me.
* Track last time for statistics reset on databases and bgwriterMagnus Hagander2011-02-101-1/+3
| | | | | | | | Tracks one counter for each database, which is reset whenever the statistics for any individual object inside the database is reset, and one counter for the background writer. Tomas Vondra, reviewed by Greg Smith
* Add views and functions to monitor hot standby query conflictsMagnus Hagander2011-01-031-1/+22
| | | | | Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
* Stamp copyrights for year 2011.Bruce Momjian2011-01-011-1/+1
|
* Add new buffers_backend_fsync field to pg_stat_bgwriter.Robert Haas2010-11-151-0/+2
| | | | | | | | | | | | This new field counts the number of times that a backend which writes a buffer out to the OS must also fsync() it. This happens when the bgwriter fsync request queue is full, and is generally detrimental to performance, so it's good to know when it's happening. Along the way, log a new message at level DEBUG1 whenever we fail to hand off an fsync, so that the problem can also be seen in examination of log files (if the logging level is cranked up high enough). Greg Smith, with minor tweaks by me.
* Remove some unnecessary tests of pgstat_track_counts.Tom Lane2010-10-121-7/+7
| | | | | | | | | | | | We may as well make pgstat_count_heap_scan() and related macros just count whenever rel->pgstat_info isn't null. Testing pgstat_track_counts buys nothing at all in the normal case where that flag is ON; and when it's OFF, the pgstat_info link will be null, so it's still a useless test. This change is unlikely to buy any noticeable performance improvement, but a cycle shaved is a cycle earned; and my investigations earlier today convinced me that we're down to the point where individual instructions in the inner execution loops are starting to matter.
* Remove cvs keywords from all files.Magnus Hagander2010-09-201-1/+1
|
* Add vacuum and analyze counters to pg_stat_*_tables views.Magnus Hagander2010-08-211-1/+5
|
* Add stats functions and views to provide access to a transaction's ownTom Lane2010-08-081-1/+4
| | | | | | | | statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
* pgindent run for 9.0Bruce Momjian2010-02-261-5/+5
|
* Add functions to reset the statistics counter for a single table/index orMagnus Hagander2010-01-281-1/+23
| | | | a single function.
* Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide sharedMagnus Hagander2010-01-191-1/+20
| | | | | | statistics of the bgwriter. Greg Smith
* Update copyright for the year 2010.Bruce Momjian2010-01-021-2/+2
|
* Revise pgstat's tracking of tuple changes to improve the reliability ofTom Lane2009-12-301-19/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
* Add support for an application_name parameter, which is displayed inTom Lane2009-11-281-2/+6
| | | | | | pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-13/+13
| | | | provided by Andrew.
* Add contrib/pg_stat_statements for server-wide tracking of statement executionTom Lane2009-01-041-2/+2
| | | | | | statistics. Takahiro Itagaki
* Update copyright for 2009.Bruce Momjian2009-01-011-2/+2
|
* Don't reset pg_class.reltuples and relpages in VACUUM, if any pages wereHeikki Linnakangas2008-12-171-2/+3
| | | | | | | | | | | | | | | | | skipped. We could update relpages anyway, but it seems better to only update it together with reltuples, because we use the reltuples/relpages ratio in the planner. Also don't update n_live_tuples in pgstat. ANALYZE in VACUUM ANALYZE now needs to update pg_class, if the VACUUM-phase didn't do so. Added some boolean-passing to let analyze_rel know if it should update pg_class or not. I also moved the relcache invalidation (to update rd_targblock) from vac_update_relstats to where RelationTruncate is called, because vac_update_relstats is not called for partial vacuums anymore. It's more obvious to send the invalidation close to the truncation that requires it. Per report by Ned T. Crigler.
* Change the pgstat logic so that the stats collector writes the stats file onlyTom Lane2008-11-031-2/+18
| | | | | | | | | | | | | | | | | | upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
* Make the temporary directory for pgstat files configurable by the GUCMagnus Hagander2008-08-151-1/+3
| | | | | | | | variable stats_temp_directory, instead of requiring the admin to mount/symlink the pg_stat_tmp directory manually. For now the config variable is PGC_POSTMASTER. Room for further improvment that would allow it to be changed on-the-fly.
* Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size.Heikki Linnakangas2008-06-301-5/+3
| | | | | | | | | As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
View Lorry Controller Status