From: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "Bug" in statistics for v7.2? |
Date: | 2002-02-13 16:15:46 |
Message-ID: | 20020213121458.H19107-100000@mail1.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
That explains it ...
profiles_faith | count
----------------+--------
0 | 485938
1 | 2
2 | 6
7 | 2
8 | 21
(5 rows)
Cool, another waste of space *sigh*
thanks ...
On Wed, 13 Feb 2002, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > Okay, if I'm understanding pg_stats at all, which I may not be, n_distinct
> > should represent # of distinct values in that row, no?
> > But, I have one field that has 5 distinct values:
> > But pg_stats is reporting 1:
>
> The pg_stats values are only, um, statistical. If 99.9% of the table is
> the same value and the other four values appear only once or twice, it's
> certainly possible for ANALYZE's sample to include only the common value
> and miss the rare ones. AFAIK that will not break anything; if you have
> an example where the planner seems to be fooled because of this, let's
> see it.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-02-13 16:21:55 | Re: Odd statistics behaviour in 7.2 |
Previous Message | Brian Hirt | 2002-02-13 16:14:40 | FATAL 2: XLogFlush: request is not satisfied |