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 with time 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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Peter Eisentraut <peter_e(at)gmx(dot)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't
force initdb. Any beta3 testers who need the fix can install it
via CREATE OR REPLACE VIEW, so forcing them to initdb seems an
unnecessary 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 it
where it is now.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler(at)lerctr(dot)org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893