Return-Path: owner-postman
Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with SMTP id JAA03840 for postgres-redist; Fri, 8 Jul 1994 09:46:06 -0700
Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199407081646.JAA03840@nobozo.CS.Berkeley.EDU>
X-Authentication-Warning: nobozo.CS.Berkeley.EDU: Host localhost.Berkeley.EDU didn't use HELO protocol
Sender: owner-postman@postgres.Berkeley.EDU
X-Return-Path: owner-postman
Received: from angular.illustra.com (angular.illustra.com [192.207.88.1]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with SMTP id JAA03830 for <postgres@nobozo.cs.berkeley.edu>; Fri, 8 Jul 1994 09:46:05 -0700
Received: from  behemoth.illustra.com (behemoth.illustra.com) 
	by  angular.illustra.com (4.1/smail2.5/06-10-94/M)
	id AA01004; Fri, 8 Jul 94 09:44:35 PDT
Received: from boulevard.illustra.com 
	by  behemoth.illustra.com (4.1/smail2.5/06-10-94/S)
	id AA17420; Fri, 8 Jul 94 09:46:08 PDT
Received: by boulevard.illustra.com (4.1/smail2.5/01-14-91)
	id AA02144; Fri, 8 Jul 94 09:47:26 PDT
Message-Id: <9407081647.AA02144@boulevard.illustra.com>
To: brunner@gdc.com (Paul Brunner)
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: vacuum command functions 
In-Reply-To: brunner's message of 8 Jul 94 12:34 EDT
Date: Fri, 08 Jul 94 09:47:25 -0700
From: Mike Olson <mao@illustra.com>
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Fri, 08 Jul 94 09:46:06 -0700
Resent-XMts: smtp

brunner@gdc.com (Paul Brunner) writes:

> I was reading a paper comparing university POSTGRES with the database system
> produced by Illustra Software, Inc. (a commercialization of the POSTGRES
> research software.) In the paper, it states that the POSTGRES vacuum command
> never actually updates these statistics. Tests I've run show the attributes
> of "relpages" and "reltuples" being updated by running the vacuum after
> appending rows to classes.

the short answer is that the university system records the number of
tuples and disk pages in a relation.  the commercial system records those
two things, plus some more info about the number of distinct values and
the range of values for each column in a relation.  the additional info
would go into the table 'pg_statistics', if the university system collected
it.

number of tuples and disk pages are useful -- they'll convince the
optimizer to use an index for a scan, if one exists.  however, depending
on the distribution of values in a column, using the index might be a
bad idea.
					mike

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================
