> However, just remember that pg_class already has a row count that we
> force in there by default.

> I was just suggesting we make that accurate if we can, even if we can
> make it accurate only 80% of the time.  Once we INSERT, it isn't
> accurate anymore anyway.  This is just an estimate, and in my mind, it
> doesn't have to be accurate in all cases.

Actually I think the accuracy of db stats is often over estimated.
For installed OLTP applications the most important thing is, that
query plans are predictable. They do not even need to be optimal, 
they only need to deliver an expected performance.

I actually do get perfect query plans without any stats, because our
indexes are perfectly matched to our statements, and in two cases we tuned
the sql appropriately (2 of >200 statements with Informix optimizer hints). For such a 
condition you actually want a rule based optimizer. The current default values during 
create table are more or less chosen to give exactly this "rule based" behavior. 
The trouble is, that after the first implicitly created stats,
the optimizer goes completely bananas, because now he thinks that one table has 1000 
(the default) rows (it actually has 10000000), but the other has 100000 and the optimizer now
knows that and chooses a different plan. And just because you copy a few rows ?

Andreas

Tue, 22 May 2001 14:31:19 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: AW: Is stats update during COPY IN really a good id
	ea?
> I actually do get perfect query plans without any stats, because
> our indexes are perfectly matched to our statements, and in two
> cases we tuned the sql appropriately (2 of >200 statements with
> Informix optimizer hints). For such a condition you actually
> want a rule based optimizer. The current default values during
> create table are more or less chosen to give exactly this "rule
> based" behavior.  The trouble is, that after the first implicitly
> created stats, the optimizer goes completely bananas, because
> now he thinks that one table has 1000 (the default) rows (it
> actually has 10000000), but the other has 100000 and the optimizer
> now knows that and chooses a different plan. And just because
> you copy a few rows ?

Oh, that is interesting.  You didn't explicitly ask for stats, but got
them anyway and that caused a problem.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 22 May 2001 08:40:41 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: AW: AW: Is stats update during COPY IN really a good id
 ea?