Обсуждение: 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