> > (2013/08/08 20:52), Vik Fearing wrote:
> >> As part of routine maintenance monitoring, it is interesting for us to
> >> have statistics on the CLUSTER command (timestamp of last run, and
> >> number of runs since stat reset) like we have for (auto)ANALYZE and
> >> (auto)VACUUM. Patch against today's HEAD attached.
Adding new fields to PgStat_StatTabEntry imposes a substantial distributed
cost, because every database stats file write-out grows by the width of those
fields times the number of tables in the database. Associated costs have been
and continue to be a pain point with large table counts:
http://www.postgresql.org/message-id/flat/1718942738eb65c8407fcd864883f4c8@fuzzy.cz
http://www.postgresql.org/message-id/flat/52268887.9010509@uptime.jp
In that light, I can't justify widening PgStat_StatTabEntry by 9.5% for this.
I recommend satisfying this monitoring need in your application by creating a
cluster_table wrapper function that issues CLUSTER and then updates statistics
you store in an ordinary table. Issue all routine CLUSTERs by way of that
wrapper function. A backend change that would help here is to extend event
triggers to cover the CLUSTER command, permitting you to inject monitoring
after plain CLUSTER and dispense with the wrapper.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
