Обсуждение: Vacuum columns in statistics tables
Is there a reason why the vacuum tracking columns in pg_stat_all_tables etc. were added before the existing columns? I find this to be a very inconvenient regression because I use the counter columns much more often. What is the rationale for that? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Is there a reason why the vacuum tracking columns in pg_stat_all_tables > etc. were added before the existing columns? I find this to be a very > inconvenient regression because I use the counter columns much more > often. What is the rationale for that? Agreed, that is quite odd: View "pg_catalog.pg_stat_all_tables" Column | Type | Modifiers------------------+--------------------------+-----------relid | oid | schemaname | name | relname | name | last_vacuum | timestamp withtime zone | last_autovacuum | timestamp with time zone | last_analyze | timestamp with time zone | last_autoanalyze| timestamp with time zone | seq_scan | bigint | seq_tup_read | bigint | idx_scan | bigint | idx_tup_fetch | bigint | n_tup_ins | bigint | n_tup_upd | bigint | n_tup_del | bigint | My only guess is it was done because the vacuum information more a characteristic of the relation than the statistics. However, I agree having them later makes more sense. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Peter Eisentraut <peter_e@gmx.net> writes: > Is there a reason why the vacuum tracking columns in pg_stat_all_tables > etc. were added before the existing columns? I find this to be a very > inconvenient regression because I use the counter columns much more > often. What is the rationale for that? Convenience is in the eye of the beholder, but perhaps a less subjective argument for putting them at the end is that it'll be less likely to break applications that do "select * from pg_stat_all_tables". Either way, though, these are mighty weak arguments for forcing initdb at the very end of the beta cycle. Can we get away with changing the views without bumping the catversion? I did something similar last week for that information_schema bug:Although this patch changes the initial catalog contents, I didn'tforce initdb. Any beta3testers who need the fix can install itvia CREATE OR REPLACE VIEW, so forcing them to initdb seems anunnecessary imposition. The stats views can likewise be fixed by dropping and recreating them, but since it's a pretty obviously user-visible change this may not be a suitable candidate for that approach. regards, tom lane
Peter Eisentraut wrote: > Is there a reason why the vacuum tracking columns in > pg_stat_all_tables etc. were added before the existing columns? I > find this to be a very inconvenient regression because I use the > counter columns much more often. What is the rationale for that? They seemed to make more sense there when I did the patch. I'm not wedded to itwhere it is now. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893