To: josh@agliodbs.com
Cc: Greg Stark <gsstark@mit.edu>,  Tom Lane <tgl@sss.pgh.pa.us>,
	David Fetter <david@fetter.org>,  pgsql-hackers@postgresql.org
Subject: Re: More thoughts about planner's cost estimates
References: <14821.1149104747@sss.pgh.pa.us> <10464.1149281016@sss.pgh.pa.us>
	<87k67zdymk.fsf@stark.xeocode.com>
	<200606021515.44174.josh@agliodbs.com>
In-Reply-To: <200606021515.44174.josh@agliodbs.com>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 02 Jun 2006 18:59:18 -0400
Message-ID: <873bendv09.fsf@stark.xeocode.com>
Lines: 44
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Josh Berkus <josh@agliodbs.com> writes:

> Greg, Tom,
> 
> > But for most users analyze doesn't really have to run as often as
> > vacuum. One sequential scan per night doesn't seem like that big a deal
> > to me.
> 
> Clearly you don't have any 0.5 TB databases.  

Actually I did not so long ago. 

Sequential scans in an OLTP query would be a disaster. But a single sequential
scan run at a controlled time wouldn't concern me as long as *all* of the
following constraints are met:

 a) You can run them at your leisure at off-peak times when your i/o bandwidth
    isn't in short supply.

  b) You don't need the results urgently so you don't care if it takes a while
     to run.

  c) You don't need many of them at the same time.

Even on your production system surely you occasionally, say, take a full
backup or run "select count(*)" or other sanity checks on the data?

> > > I'd still be worried about the CPU pain though.  ANALYZE can afford to
> > > expend a pretty fair number of cycles per sampled tuple, but with a
> > > whole-table sample that's going to add up.
> 
> Agreed.  Despite conventional wisdom, most PostgreSQL databases ... even 
> those with high level OLTP or very large DW ... are CPU-bound.    We 
> really don't want an ANALYZE which is an order-of-magnitude increase in 
> CPU activity.

I don't think Tom was actually expressing concern about ANALYZE becoming more
expensive, but about tying ANALYZE and VACUUM together and making VACUUM more
expensive. VACUUM is something we want to encourage people to think they can
run all day long, not just occasionally.

-- 
greg