On 2/22/17 06:31, Jim Mlodgenski wrote: > Matviews already show up in the pg_stat_*_tables and the patch does > leverage the existing pg_stat_*_tables underlying structure, but it > creates more meaningful pg_stat_*_matviews leaving out things like > insert and update counts.
But fields like seq_scans and last_analyze are then redundant between the *_tables view and the *_matviews view. Maybe it would make more sense to introduce a new view like you propose and not show them in *_tables anymore? > I was originally thinking 2 patches, but I couldn't think of a way to > trigger the analyze reliably without adding a refresh count or sending > bogus stats. We can certainly send a stats message containing the number > of rows inserted by the refresh, but are we going to also send the > number of deletes as well? Consider a matview that has month to date > data. At the end of the month, there will be about 30n live tuples. The > next day on the new month, there will be n inserts with the stats > thinking there are 30n live tuples which is below the analyze scale > factor. We want to analyze the matview on the first of the day of the > new month, but it wouldn't be triggered for a few days. We can have > REFRESH also track live tuples, but it was quickly becoming a slippery > slope of changing behavior for a back patch. Maybe that's OK and we can > go down that road. For those not reading the patch, it introduces a new reloption autovacuum_analyze_refresh_threshold that determines when to autoanalyze a materialized view. What behavior would we like by default? Refreshing a materialized view is a pretty expensive operation, so I think scheduling an analyze quite aggressively right afterwards is often what you want. I think sending a stats message with the number of inserted rows could make sense. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
