Just for closure I ended up doing
ALTER TABLE bars ALTER COLUMN bars_id SET STATISTICS 500;
On Thu, Aug 7, 2008 at 7:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua Shanks" <[EMAIL PROTECTED]> writes:
>> How do I increase the stats target for just one column?
>
> Look under ALTER TABLE.
>
>
"Joshua Shanks" <[EMAIL PROTECTED]> writes:
> How do I increase the stats target for just one column?
Look under ALTER TABLE.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.
Yeah with default_statistics_target at 500 most_common_vals had 4
values with the fourth having a frequency of 1.5% and distinct have
250+ in it.
How do I increase the stats target for just one column?
On Thu, Aug 7, 2008 at 6:48 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua Shanks" <[EMAIL P
"Joshua Shanks" <[EMAIL PROTECTED]> writes:
> SELECT null_frac, n_distinct, most_common_vals, most_common_freqs FROM
> pg_stats WHERE tablename = 'bars' AND attname='bars_id';
> null_frac | n_distinct | most_common_vals | most_common_freqs
> ---++--+
On Thu, Aug 7, 2008 at 5:38 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Measuring n_distinct from a sample is inherently difficult and unreliable.
> When 98% of your table falls into those categories it's leaving very few
> chances for the sample to find many other distinct values.
>
> I haven't
"Joshua Shanks" <[EMAIL PROTECTED]> writes:
> Those 3 values in reality and in the stats account for 98% of the
> rows. actual distinct values are around 350
Measuring n_distinct from a sample is inherently difficult and unreliable.
When 98% of your table falls into those categories it's leaving
On Thu, Aug 7, 2008 at 4:12 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, you haven't told us how big any of these tables are, so it's
> hard to tell if the n_distinct value is wrong or not ... but in
> any case I don't think that the stats on attr1 have anything to do
> with your problem. The r
"Joshua Shanks" <[EMAIL PROTECTED]> writes:
> It seems obvious that the stats on attr1 at the current level are
> inaccurate as there are over 100,000 unique enteries in the table.
Well, you haven't told us how big any of these tables are, so it's
hard to tell if the n_distinct value is wrong or n
On Wed, Aug 6, 2008 at 10:24 PM, Craig Ringer
<[EMAIL PROTECTED]> wrote:
> OK, that's interesting. There are ways to examine Pg's statistics on
> columns, get an idea of which stats might be less than accurate, etc,
> but I'm not really familiar enough with it all to give you any useful
> advice on
Joshua Shanks wrote:
>> - Have you changed the random page cost on either installation?
>
> This is whatever the default is for both boxes (commented config file says
> 4.0)
>
>> - Have both installations had VACUUM ANALYZE run recently?
>
> This is the first thing I did and didn't seem to do a
> - Have you changed the random page cost on either installation?
This is whatever the default is for both boxes (commented config file says 4.0)
> - Have both installations had VACUUM ANALYZE run recently?
This is the first thing I did and didn't seem to do anything.
Oddly enough I just went a
Joshua Shanks wrote:
> This query is run on a test system just after a backup of the database
> has been restored and it does exactly what I expect it to do
[snip]
Obvious questions:
- Have you changed the random page cost on either installation?
- Have both installations had VACUUM ANALYZE run
12 matches
Mail list logo
