From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> |
Cc: | pgsql(at)mohawksoft(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Query optimizer 8.0.1 (and 8.0) |
Date: | 2005-02-08 13:57:34 |
Message-ID: | 20050208135734.GY10437@ns.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Mark Kirkwood (markir(at)coretech(dot)co(dot)nz) wrote:
> I can see your point, however I wonder if the issue is that the default
> stats settings of '10' (3000 rows, 10 histogram buckets) is too low, and
> maybe we should consider making a higher value (say '100') the default.
Personally, I think that'd be reasonable.
> The idea of either automatically increasing sample size for large
> tables, or doing a few more samplings with different sizes and examining
> the stability of the estimates is rather nice, provided we can keep the
> runtime for ANALYZE to reasonable limits, I guess :-)
I also agree with this and personally don't mind *too* much if analyze
takes a little while on a large table to get decent statistics for it.
One thing I was wondering about though is if we use the index to
get some of the statistics information? Would it be possible, or
reasonable? Do we already? I dunno, just some thoughts there, I keep
hearing about the number of rows that are sampled and I would have
thought it'd make sense to scan the index for things like the number of
distinct values...
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Buttafuoco | 2005-02-08 14:14:35 | Fw: Re: float4 regression test failed on linux parisc |
Previous Message | pgsql | 2005-02-08 13:48:02 | Re: Query optimizer 8.0.1 (and 8.0) |