AW: AW: Is stats update during COPY IN really a good id ea?

> 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