Postgres Pro
Downloads
Home   >   mailing lists

Thread: pg_stats question

pg_stats question

From
Joseph Shraibman
Date:
I notice in 7.4.1 that if I do:
ALTER TABLE <tab> ALTER <col> SET STATISTICS 100;
... that not necc. 100 values are stored in pg_stats, but in 7.3.4 it
did.  Bug or expected behaviour?

Re: pg_stats question

From
Tom Lane
Date:
Joseph Shraibman <jks@selectacast.net> writes:
> I notice in 7.4.1 that if I do:
> ALTER TABLE <tab> ALTER <col> SET STATISTICS 100;
> ... that not necc. 100 values are stored in pg_stats, but in 7.3.4 it
> did.  Bug or expected behaviour?

It wasn't necessarily 100 values in 7.3, either.

As a trivial counterexample, if you have less than 100 distinct values
in your column, there definitely won't be 100 values in the
most-common-values list ...

            regards, tom lane

Re: pg_stats question

From
Joseph Shraibman
Date:
Tom Lane wrote:
> Joseph Shraibman <jks@selectacast.net> writes:
>
>>I notice in 7.4.1 that if I do:
>>ALTER TABLE <tab> ALTER <col> SET STATISTICS 100;
>>... that not necc. 100 values are stored in pg_stats, but in 7.3.4 it
>>did.  Bug or expected behaviour?
>
>
> It wasn't necessarily 100 values in 7.3, either.
>
> As a trivial counterexample, if you have less than 100 distinct values
> in your column, there definitely won't be 100 values in the
> most-common-values list ...
>


Right, but in this case I'm sure I have over 200 values.

Re: pg_stats question

From
Tom Lane
Date:
Joseph Shraibman <jks@selectacast.net> writes:
> Tom Lane wrote:
>> As a trivial counterexample, if you have less than 100 distinct values
>> in your column, there definitely won't be 100 values in the
>> most-common-values list ...

> Right, but in this case I'm sure I have over 200 values.

Still, ANALYZE might not have seen all of them within its sample set of
rows.  There's inherently some sampling error involved in the process
(at least in 7.2 and later).

I don't believe 7.4 has any significant difference from 7.3 in this
area.

            regards, tom lane