pgsql: Expose the estimation of number of changed tuples since last ana
Expose the estimation of number of changed tuples since last analyze
This value, now pg_stat_all_tables.n_mod_since_analyze, was already
tracked and used by autovacuum, but not exposed to the user.
Mark Kirkwood, review by Laurenz Albe
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/c87ff71f374652936a6089215a30998492b14d52
Modified Files
--------------
doc/src/sgml/monitoring.sgml | 5 +++++
src/backend/catalog/system_views.sql | 1 +
src/backend/utils/adt/pgstatfuncs.c | 17 +++++++++++++++++
src/include/catalog/catversion.h | 2 +-
src/include/catalog/pg_proc.h | 2 ++
src/test/regress/expected/rules.out | 3 +++
6 files changed, 29 insertions(+), 1 deletion(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Expose the estimation of number of changed tuples since last analyze
This value, now pg_stat_all_tables.n_mod_since_analyze, was already
tracked and used by autovacuum, but not exposed to the user.
I though you agreed on a shorter name ? (n_mod_tuple ?)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
On Fri, Jul 5, 2013 at 3:43 PM, Cédric Villemain <cedric@2ndquadrant.com> wrote:
Expose the estimation of number of changed tuples since last analyze
This value, now pg_stat_all_tables.n_mod_since_analyze, was already
tracked and used by autovacuum, but not exposed to the user.I though you agreed on a shorter name ? (n_mod_tuple ?)
No, I suggested a shorter name, but was convinced that this would
likely be more confusing..
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Le vendredi 5 juillet 2013 15:44:55, Magnus Hagander a écrit :
On Fri, Jul 5, 2013 at 3:43 PM, Cédric Villemain <cedric@2ndquadrant.com>
wrote:
Expose the estimation of number of changed tuples since last analyze
This value, now pg_stat_all_tables.n_mod_since_analyze, was already
tracked and used by autovacuum, but not exposed to the user.I though you agreed on a shorter name ? (n_mod_tuple ?)
No, I suggested a shorter name, but was convinced that this would
likely be more confusing..
I understand (I read the review thread). is it correct to interpret that as
the number of tuples bloating the table ?
I supposed that hot_update was not tracked for autovacuum task, but I have a
doubt now .
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
On Fri, Jul 5, 2013 at 4:23 PM, Cédric Villemain <cedric@2ndquadrant.com> wrote:
Le vendredi 5 juillet 2013 15:44:55, Magnus Hagander a écrit :
On Fri, Jul 5, 2013 at 3:43 PM, Cédric Villemain <cedric@2ndquadrant.com>
wrote:
Expose the estimation of number of changed tuples since last analyze
This value, now pg_stat_all_tables.n_mod_since_analyze, was already
tracked and used by autovacuum, but not exposed to the user.I though you agreed on a shorter name ? (n_mod_tuple ?)
No, I suggested a shorter name, but was convinced that this would
likely be more confusing..I understand (I read the review thread). is it correct to interpret that as
the number of tuples bloating the table ?
No. That would n_dead_tup.
It's the number of tuples that changes the distribution of values and
would thus require ANALYZE. not VACUUM.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers