More vacuum stats
I noticed that we were already tracking the information about when an
autovacuum worker was last started in a database, but this information
was not exposed. The attached patch puts this column in
pg_stat_database.
Was there any particular reason why this wasn't exposed before that
I've missed, making this a bad addition? :-)
Oh, and this time, I *have* included updates to the regression tests.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
vac_db.patchapplication/octet-stream; name=vac_db.patchDownload
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 7b65011..b8f5d41 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -276,7 +276,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
number of transactions committed and rolled back in that database,
total disk blocks read, total buffer hits (i.e., block
read requests avoided by finding the block already in buffer cache),
- number of rows returned, fetched, inserted, updated and deleted.
+ number of rows returned, fetched, inserted, updated and deleted, and
+ the last time an autovacuum worker was started in this database.
</entry>
</row>
@@ -598,6 +599,14 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</row>
<row>
+ <entry><literal><function>pg_stat_get_db_last_autovacuum</function>(<type>oid</type>)</literal></entry>
+ <entry><type>timestamptz</type></entry>
+ <entry>
+ The last time an autovacuum worker process was started in database
+ </entry>
+ </row>
+
+ <row>
<entry><literal><function>pg_stat_get_numscans</function>(<type>oid</type>)</literal></entry>
<entry><type>bigint</type></entry>
<entry>
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index 9fbe70d..ef2ac7d 100644
--- a/src/backend/catalog/system_views.sql
+++ b/src/backend/catalog/system_views.sql
@@ -394,7 +394,8 @@ CREATE VIEW pg_stat_database AS
pg_stat_get_db_tuples_fetched(D.oid) AS tup_fetched,
pg_stat_get_db_tuples_inserted(D.oid) AS tup_inserted,
pg_stat_get_db_tuples_updated(D.oid) AS tup_updated,
- pg_stat_get_db_tuples_deleted(D.oid) AS tup_deleted
+ pg_stat_get_db_tuples_deleted(D.oid) AS tup_deleted,
+ pg_stat_get_db_last_autovacuum_time(D.oid) AS last_autovacuum
FROM pg_database D;
CREATE VIEW pg_stat_user_functions AS
diff --git a/src/backend/utils/adt/pgstatfuncs.c b/src/backend/utils/adt/pgstatfuncs.c
index 476d83f..4eb3c2b 100644
--- a/src/backend/utils/adt/pgstatfuncs.c
+++ b/src/backend/utils/adt/pgstatfuncs.c
@@ -71,6 +71,7 @@ extern Datum pg_stat_get_db_tuples_fetched(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_db_tuples_inserted(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_db_tuples_updated(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_db_tuples_deleted(PG_FUNCTION_ARGS);
+extern Datum pg_stat_get_db_last_autovacuum_time(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_bgwriter_timed_checkpoints(PG_FUNCTION_ARGS);
extern Datum pg_stat_get_bgwriter_requested_checkpoints(PG_FUNCTION_ARGS);
@@ -1129,6 +1130,24 @@ pg_stat_get_db_tuples_deleted(PG_FUNCTION_ARGS)
}
Datum
+pg_stat_get_db_last_autovacuum_time(PG_FUNCTION_ARGS)
+{
+ Oid dbid = PG_GETARG_OID(0);
+ TimestampTz result;
+ PgStat_StatDBEntry *dbentry;
+
+ if ((dbentry = pgstat_fetch_stat_dbentry(dbid)) == NULL)
+ result = 0;
+ else
+ result = dbentry->last_autovac_time;
+
+ if (result == 0)
+ PG_RETURN_NULL();
+ else
+ PG_RETURN_TIMESTAMPTZ(result);
+}
+
+Datum
pg_stat_get_bgwriter_timed_checkpoints(PG_FUNCTION_ARGS)
{
PG_RETURN_INT64(pgstat_fetch_global()->timed_checkpoints);
diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h
index 1c53418..3eedef2 100644
--- a/src/include/catalog/pg_proc.h
+++ b/src/include/catalog/pg_proc.h
@@ -3037,6 +3037,8 @@ DATA(insert OID = 3056 ( pg_stat_get_analyze_count PGNSP PGUID 12 1 0 0 f f f t
DESCR("statistics: number of manual analyzes for a table");
DATA(insert OID = 3057 ( pg_stat_get_autoanalyze_count PGNSP PGUID 12 1 0 0 f f f t f s 1 0 20 "26" _null_ _null_ _null_ _null_ pg_stat_get_autoanalyze_count _null_ _null_ _null_ ));
DESCR("statistics: number of auto analyzes for a table");
+DATA(insert OID = 3058 ( pg_stat_get_db_last_autovacuum_time PGNSP PGUID 12 1 0 0 f f f t f s 1 0 1184 "26" _null_ _null_ _null_ _null_ pg_stat_get_db_last_autovacuum_time _null_ _null_ _null_ ));
+DESCR("statistics: last auto vacuum time for a database");
DATA(insert OID = 1936 ( pg_stat_get_backend_idset PGNSP PGUID 12 1 100 0 f f f t t s 0 0 23 "" _null_ _null_ _null_ _null_ pg_stat_get_backend_idset _null_ _null_ _null_ ));
DESCR("statistics: currently active backend IDs");
DATA(insert OID = 2022 ( pg_stat_get_activity PGNSP PGUID 12 1 100 0 f f f f t s 1 0 2249 "23" "{23,26,23,26,25,25,16,1184,1184,1184,869,23}" "{i,o,o,o,o,o,o,o,o,o,o,o}" "{pid,datid,procpid,usesysid,application_name,current_query,waiting,xact_start,query_start,backend_start,client_addr,client_port}" _null_ pg_stat_get_activity _null_ _null_ _null_ ));
diff --git a/src/test/regress/expected/rules.out b/src/test/regress/expected/rules.out
index ee3bd3b..76c5928 100644
--- a/src/test/regress/expected/rules.out
+++ b/src/test/regress/expected/rules.out
@@ -1293,7 +1293,7 @@ SELECT viewname, definition FROM pg_views WHERE schemaname <> 'information_schem
pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname AS indexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read, pg_stat_get_tuples_fetched(i.oid) AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = ANY (ARRAY['r'::"char", 't'::"char"]));
pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS seq_scan, pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, (sum(pg_stat_get_numscans(i.indexrelid)))::bigint AS idx_scan, ((sum(pg_stat_get_tuples_fetched(i.indexrelid)))::bigint + pg_stat_get_tuples_fetched(c.oid)) AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins, pg_stat_get_tuples_updated(c.oid) AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del, pg_stat_get_tuples_hot_updated(c.oid) AS n_tup_hot_upd, pg_stat_get_live_tuples(c.oid) AS n_live_tup, pg_stat_get_dead_tuples(c.oid) AS n_dead_tup, pg_stat_get_last_vacuum_time(c.oid) AS last_vacuum, pg_stat_get_last_autovacuum_time(c.oid) AS last_autovacuum, pg_stat_get_last_analyze_time(c.oid) AS last_analyze, pg_stat_get_last_autoanalyze_time(c.oid) AS last_autoanalyze, pg_stat_get_vacuum_count(c.oid) AS vacuum_count, pg_stat_get_autovacuum_count(c.oid) AS autovacuum_count, pg_stat_get_analyze_count(c.oid) AS analyze_count, pg_stat_get_autoanalyze_count(c.oid) AS autoanalyze_count FROM ((pg_class c LEFT JOIN pg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = ANY (ARRAY['r'::"char", 't'::"char"])) GROUP BY c.oid, n.nspname, c.relname;
pg_stat_bgwriter | SELECT pg_stat_get_bgwriter_timed_checkpoints() AS checkpoints_timed, pg_stat_get_bgwriter_requested_checkpoints() AS checkpoints_req, pg_stat_get_bgwriter_buf_written_checkpoints() AS buffers_checkpoint, pg_stat_get_bgwriter_buf_written_clean() AS buffers_clean, pg_stat_get_bgwriter_maxwritten_clean() AS maxwritten_clean, pg_stat_get_buf_written_backend() AS buffers_backend, pg_stat_get_buf_alloc() AS buffers_alloc;
- pg_stat_database | SELECT d.oid AS datid, d.datname, pg_stat_get_db_numbackends(d.oid) AS numbackends, pg_stat_get_db_xact_commit(d.oid) AS xact_commit, pg_stat_get_db_xact_rollback(d.oid) AS xact_rollback, (pg_stat_get_db_blocks_fetched(d.oid) - pg_stat_get_db_blocks_hit(d.oid)) AS blks_read, pg_stat_get_db_blocks_hit(d.oid) AS blks_hit, pg_stat_get_db_tuples_returned(d.oid) AS tup_returned, pg_stat_get_db_tuples_fetched(d.oid) AS tup_fetched, pg_stat_get_db_tuples_inserted(d.oid) AS tup_inserted, pg_stat_get_db_tuples_updated(d.oid) AS tup_updated, pg_stat_get_db_tuples_deleted(d.oid) AS tup_deleted FROM pg_database d;
+ pg_stat_database | SELECT d.oid AS datid, d.datname, pg_stat_get_db_numbackends(d.oid) AS numbackends, pg_stat_get_db_xact_commit(d.oid) AS xact_commit, pg_stat_get_db_xact_rollback(d.oid) AS xact_rollback, (pg_stat_get_db_blocks_fetched(d.oid) - pg_stat_get_db_blocks_hit(d.oid)) AS blks_read, pg_stat_get_db_blocks_hit(d.oid) AS blks_hit, pg_stat_get_db_tuples_returned(d.oid) AS tup_returned, pg_stat_get_db_tuples_fetched(d.oid) AS tup_fetched, pg_stat_get_db_tuples_inserted(d.oid) AS tup_inserted, pg_stat_get_db_tuples_updated(d.oid) AS tup_updated, pg_stat_get_db_tuples_deleted(d.oid) AS tup_deleted, pg_stat_get_db_last_autovacuum_time(d.oid) AS last_autovacuum FROM pg_database d;
pg_stat_sys_indexes | SELECT pg_stat_all_indexes.relid, pg_stat_all_indexes.indexrelid, pg_stat_all_indexes.schemaname, pg_stat_all_indexes.relname, pg_stat_all_indexes.indexrelname, pg_stat_all_indexes.idx_scan, pg_stat_all_indexes.idx_tup_read, pg_stat_all_indexes.idx_tup_fetch FROM pg_stat_all_indexes WHERE ((pg_stat_all_indexes.schemaname = ANY (ARRAY['pg_catalog'::name, 'information_schema'::name])) OR (pg_stat_all_indexes.schemaname ~ '^pg_toast'::text));
pg_stat_sys_tables | SELECT pg_stat_all_tables.relid, pg_stat_all_tables.schemaname, pg_stat_all_tables.relname, pg_stat_all_tables.seq_scan, pg_stat_all_tables.seq_tup_read, pg_stat_all_tables.idx_scan, pg_stat_all_tables.idx_tup_fetch, pg_stat_all_tables.n_tup_ins, pg_stat_all_tables.n_tup_upd, pg_stat_all_tables.n_tup_del, pg_stat_all_tables.n_tup_hot_upd, pg_stat_all_tables.n_live_tup, pg_stat_all_tables.n_dead_tup, pg_stat_all_tables.last_vacuum, pg_stat_all_tables.last_autovacuum, pg_stat_all_tables.last_analyze, pg_stat_all_tables.last_autoanalyze, pg_stat_all_tables.vacuum_count, pg_stat_all_tables.autovacuum_count, pg_stat_all_tables.analyze_count, pg_stat_all_tables.autoanalyze_count FROM pg_stat_all_tables WHERE ((pg_stat_all_tables.schemaname = ANY (ARRAY['pg_catalog'::name, 'information_schema'::name])) OR (pg_stat_all_tables.schemaname ~ '^pg_toast'::text));
pg_stat_user_functions | SELECT p.oid AS funcid, n.nspname AS schemaname, p.proname AS funcname, pg_stat_get_function_calls(p.oid) AS calls, (pg_stat_get_function_time(p.oid) / 1000) AS total_time, (pg_stat_get_function_self_time(p.oid) / 1000) AS self_time FROM (pg_proc p LEFT JOIN pg_namespace n ON ((n.oid = p.pronamespace))) WHERE ((p.prolang <> (12)::oid) AND (pg_stat_get_function_calls(p.oid) IS NOT NULL));
Magnus Hagander escreveu:
Was there any particular reason why this wasn't exposed before that
I've missed, making this a bad addition? :-)
Not that I know of. Good catch. ;)
--
Euler Taveira de Oliveira
http://www.timbira.com/
Magnus Hagander <magnus@hagander.net> writes:
I noticed that we were already tracking the information about when an
autovacuum worker was last started in a database, but this information
was not exposed. The attached patch puts this column in
pg_stat_database.
Was there any particular reason why this wasn't exposed before that
I've missed, making this a bad addition? :-)
I think that's an implementation detail. If we expose it then we'll
be forced to track it forevermore, regardless of whether the AV launcher
actually needs it in the future. (In particular, the assumption that
this is tracked per-database and not per-something-else seems like an
artifact of the current AV launching algorithm.)
So I'd like to see a positive argument why this is important for users
to know, rather than merely "we should expose every conceivable detail
by default". Why wouldn't a user care more about last AV time for a
specific table, which we already do expose?
regards, tom lane
On Sun, Aug 22, 2010 at 17:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
I noticed that we were already tracking the information about when an
autovacuum worker was last started in a database, but this information
was not exposed. The attached patch puts this column in
pg_stat_database.Was there any particular reason why this wasn't exposed before that
I've missed, making this a bad addition? :-)I think that's an implementation detail. If we expose it then we'll
be forced to track it forevermore, regardless of whether the AV launcher
actually needs it in the future. (In particular, the assumption that
this is tracked per-database and not per-something-else seems like an
artifact of the current AV launching algorithm.)
That's a good point. OTOH, if we removed the feature, it seems it
would be reasonable to remove the column from the statistics view as
well. That *could* happen in other stats views as well.
So I'd like to see a positive argument why this is important for users
to know, rather than merely "we should expose every conceivable detail
by default". Why wouldn't a user care more about last AV time for a
specific table, which we already do expose?
You need to connect to every database to do that. If you have many
databases, that's a lot of overhead particularly if you're doing tihs
for regular monitoring. Plus, those views will only track when
autovacuum actually *did* something.
Being able to see that autovacuum hasn't even touched a database for
too long would be an early-indicator that you have some issues with
it.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Sun, Aug 22, 2010 at 17:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely "we should expose every conceivable detail
by default". �Why wouldn't a user care more about last AV time for a
specific table, which we already do expose?
You need to connect to every database to do that. If you have many
databases, that's a lot of overhead particularly if you're doing tihs
for regular monitoring. Plus, those views will only track when
autovacuum actually *did* something.
Well, the last-launch-time doesn't prove that autovacuum actually *did*
something ;-).
Being able to see that autovacuum hasn't even touched a database for
too long would be an early-indicator that you have some issues with
it.
With the current AV launch algorithm, unless you have very serious
system-wide issues there will be a worker launched into each database
approximately every autovacuum_naptime seconds. AFAICS this does not
tell you anything interesting about whether AV is getting its work done.
regards, tom lane
On Sun, Aug 22, 2010 at 18:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Sun, Aug 22, 2010 at 17:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely "we should expose every conceivable detail
by default". Why wouldn't a user care more about last AV time for a
specific table, which we already do expose?You need to connect to every database to do that. If you have many
databases, that's a lot of overhead particularly if you're doing tihs
for regular monitoring. Plus, those views will only track when
autovacuum actually *did* something.Well, the last-launch-time doesn't prove that autovacuum actually *did*
something ;-).
Well, it would tell you it considered doing something ;)
Being able to see that autovacuum hasn't even touched a database for
too long would be an early-indicator that you have some issues with
it.With the current AV launch algorithm, unless you have very serious
system-wide issues there will be a worker launched into each database
approximately every autovacuum_naptime seconds. AFAICS this does not
tell you anything interesting about whether AV is getting its work done.
Well, if you have all your autovacuum workers tied up with vacuuming
large tables, then it wouldn't AFAIK. I'm not sure if that counts as
your "very serious system-wide issues", but it's certainly a case
that's interesting for the admin to know about.
But thinking more about that, you ca nfigure that out with a SELECT
count(*) FROM pg_stat_activity WHERE current_query LIKE 'autovacuum:
%' if I'm not mistaken.
It can also be used to find out if the launcher is somehoiw stuck, but
that would be a bug and we don't generally put counters in the stats
views to expose possible bugs, only to track interesting statistics.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Sun, Aug 22, 2010 at 18:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
With the current AV launch algorithm, unless you have very serious
system-wide issues there will be a worker launched into each database
approximately every autovacuum_naptime seconds. �AFAICS this does not
tell you anything interesting about whether AV is getting its work done.
Well, if you have all your autovacuum workers tied up with vacuuming
large tables, then it wouldn't AFAIK. I'm not sure if that counts as
your "very serious system-wide issues", but it's certainly a case
that's interesting for the admin to know about.
But thinking more about that, you ca nfigure that out with a SELECT
count(*) FROM pg_stat_activity WHERE current_query LIKE 'autovacuum:
%' if I'm not mistaken.
It can also be used to find out if the launcher is somehoiw stuck, but
that would be a bug and we don't generally put counters in the stats
views to expose possible bugs, only to track interesting statistics.
Yeah. Given the current worker-launch algorithm, these times just don't
strike me as all that interesting in practice. If we were to change to
a different algorithm, it's possible that it'd become worthwhile to
expose them --- but it's equally possible that some other data would be
useful instead. So my feeling remains that we should leave well enough
alone.
regards, tom lane
Tom Lane wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely "we should expose every conceivable detail
by default". Why wouldn't a user care more about last AV time for a
specific table, which we already do expose?
What I actually want here is for the time that the last table autovacuum
started, adding to the finish time currently exposed by
pg_stat_user_tables. "How long did the last {auto}vacuum on <x> take to
run?" is a FAQ on busy systems here. If I could compute that from a
pair of columns, it's a major step toward answering even more
interesting questions like "how does this set of cost delay parameters
turn into an approximate MB/s worth of processing rate on my tables?".
This is too important of a difficult tuning exercise to leave to log
scraping forever.
I'd rather have that and look at for "SELECT max(last_autovacuum_start)
FROM pg_stat_user_tables" to diagnose the sort of problems this patch
seems to aim at helping.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
On Mon, Aug 23, 2010 at 16:28, Greg Smith <greg@2ndquadrant.com> wrote:
Tom Lane wrote:
So I'd like to see a positive argument why this is important for users
to know, rather than merely "we should expose every conceivable detail
by default". Why wouldn't a user care more about last AV time for a
specific table, which we already do expose?What I actually want here is for the time that the last table autovacuum
started, adding to the finish time currently exposed by pg_stat_user_tables.
"How long did the last {auto}vacuum on <x> take to run?" is a FAQ on busy
systems here. If I could compute that from a pair of columns, it's a major
step toward answering even more interesting questions like "how does this
set of cost delay parameters turn into an approximate MB/s worth of
processing rate on my tables?". This is too important of a difficult tuning
exercise to leave to log scraping forever.
Now, that would be quite useful. That'd require another stats message,
since we don't send anything on autovacuum start, but I don't think
the overhead of that is anything we need to worry about - in
comparison to an actual vacuum...
Do we want that for both vacuum and autovacuum? vacuum and analyze?
We could also store last_autovacuum_vacuum_duration - is that better
or worse than start and end time?
I'd rather have that and look at for "SELECT max(last_autovacuum_start) FROM
pg_stat_user_tables" to diagnose the sort of problems this patch seems to
aim at helping.
Agreed. Consider this patch withdrawn.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Aug 23, 2010 at 16:28, Greg Smith <greg@2ndquadrant.com> wrote:
What I actually want here is for the time that the last table autovacuum
started, adding to the finish time currently exposed by pg_stat_user_tables.
Now, that would be quite useful. That'd require another stats message,
since we don't send anything on autovacuum start, but I don't think
the overhead of that is anything we need to worry about - in
comparison to an actual vacuum...
No, you wouldn't really need an extra message, you could just send both
start and finish times in the completion message. I'm not sure that
having last start time update before last end time would be a good idea
anyway.
But in any case it's true that an extra message wouldn't be a
significant cost. What I'd be more concerned about is the stats table
bloat from adding yet another per-table field. That could be a lot of
space on an installation with lots of tables.
We could also store last_autovacuum_vacuum_duration - is that better
or worse than start and end time?
No, I think you want to know the actual time not only the duration.
regards, tom lane
On Mon, Aug 23, 2010 at 16:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Aug 23, 2010 at 16:28, Greg Smith <greg@2ndquadrant.com> wrote:
What I actually want here is for the time that the last table autovacuum
started, adding to the finish time currently exposed by pg_stat_user_tables.Now, that would be quite useful. That'd require another stats message,
since we don't send anything on autovacuum start, but I don't think
the overhead of that is anything we need to worry about - in
comparison to an actual vacuum...No, you wouldn't really need an extra message, you could just send both
start and finish times in the completion message. I'm not sure that
having last start time update before last end time would be a good idea
anyway.
Hmm, good point. We'd just need an extra field in that message.
But in any case it's true that an extra message wouldn't be a
significant cost. What I'd be more concerned about is the stats table
bloat from adding yet another per-table field. That could be a lot of
space on an installation with lots of tables.We could also store last_autovacuum_vacuum_duration - is that better
or worse than start and end time?No, I think you want to know the actual time not only the duration.
Well, you could calculate one from the other - especially if one takes
less size, per your comment above.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Aug 23, 2010 at 16:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
We could also store last_autovacuum_vacuum_duration - is that better
or worse than start and end time?No, I think you want to know the actual time not only the duration.
Well, you could calculate one from the other - especially if one takes
less size, per your comment above.
With alignment considerations, adding a field is going to cost 8 bytes;
whether it's a timestamp or a duration isn't going to matter. I'd be
inclined to store the timestamp, it just seems more like the base datum.
regards, tom lane