On Tue, May 23, 2006 at 05:00:13PM -0600, Ed L. wrote:
> On Tuesday May 23 2006 4:55 pm, Jim C. Nasby wrote:
> > Well, I did find one reason not to go ape with this: the
> > number of pages analyzed scales with the number of buckets, so
> > doubling the statistics target will roughly double the ANA
On Tuesday May 23 2006 4:55 pm, Jim C. Nasby wrote:
> Well, I did find one reason not to go ape with this: the
> number of pages analyzed scales with the number of buckets, so
> doubling the statistics target will roughly double the ANALYZE
> time for any table over 6000 pages (though the effect is
On Tue, May 23, 2006 at 06:18:07PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Mon, May 22, 2006 at 06:43:22PM -0400, Tom Lane wrote:
> >> It would be nice to have some *evidence*, not unsupported handwaving.
>
> > If someone has an idea on how to actually get that e
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Mon, May 22, 2006 at 06:43:22PM -0400, Tom Lane wrote:
>> It would be nice to have some *evidence*, not unsupported handwaving.
> If someone has an idea on how to actually get that evidence, I'm all
> ears.
Well, for example, actually measuring the
That being said, 10 is fairly small and I often find myself setting the
value to at least 250 just to keep it out of my way.
And ditto (though I normally go for 100).
Have you ever run into problems from setting this too high?
No. Except that it does increase the time it takes to analyze wh
On Mon, May 22, 2006 at 05:55:16PM -0700, Joshua D. Drake wrote:
>
> >The reason the default is currently 10 is just conservatism: it was
> >already an order of magnitude better than what it replaced (a *single*
> >representative value) and I didn't feel I had the evidence to justify
> >higher val
On Mon, May 22, 2006 at 06:43:22PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Wed, May 17, 2006 at 10:29:14PM -0400, Tom Lane wrote:
> >> The reason the default is currently 10 is just conservatism: it was
> >> already an order of magnitude better than what it replac
On Monday May 22 2006 4:43 pm, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Wed, May 17, 2006 at 10:29:14PM -0400, Tom Lane wrote:
> >> The reason the default is currently 10 is just
> >> conservatism: it was already an order of magnitude better
> >> than what it replaced (a
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
Is the only downside to a large value planning speed? It seems it would
be hard to bloat that too much, except in cases where people are
striving for millisecond response times, and those folks had better know
enough about tuning to be
The reason the default is currently 10 is just conservatism: it was
already an order of magnitude better than what it replaced (a *single*
representative value) and I didn't feel I had the evidence to justify
higher values. It's become clear that the default ought to be higher,
but I've still g
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 17, 2006 at 10:29:14PM -0400, Tom Lane wrote:
>> The reason the default is currently 10 is just conservatism: it was
>> already an order of magnitude better than what it replaced (a *single*
>> representative value) and I didn't feel I had th
On Wed, May 17, 2006 at 10:29:14PM -0400, Tom Lane wrote:
> The reason the default is currently 10 is just conservatism: it was
> already an order of magnitude better than what it replaced (a *single*
> representative value) and I didn't feel I had the evidence to justify
> higher values. It's bec
Peter Kovacs wrote:
> Sorry for the naive question, but: is there a problem with analyze doing
> full table scans? Analyze will not lock anything, will it?
It used to do that, but the read overhead was too great.
---
>
> P
Sorry for the naive question, but: is there a problem with analyze doing
full table scans? Analyze will not lock anything, will it?
Peter
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
"Ed L." <[EMAIL PROTECTED]> writes:
So, does this sound like we just happened to get repeat
Tom Lane <[EMAIL PROTECTED]> writes:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > So, does this sound like we just happened to get repeatedly
> > horribly unrepresentative random samples with stats target at
> > 10? Are we at the mercy of randomness here? Or is there a
> > better preventive proc
"Ed L." <[EMAIL PROTECTED]> writes:
> So, does this sound like we just happened to get repeatedly
> horribly unrepresentative random samples with stats target at
> 10? Are we at the mercy of randomness here? Or is there a
> better preventive procedure we can follow to systematically
> identif
On Wednesday May 17 2006 1:26 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > I'm trying to understand what happened here, and I have a
> > theory.
>
> The problem is the horrid misestimation of the selectivity of
> "nursestation_key = 40":
>
>-> Bitmap Index Scan on
"Ed L." <[EMAIL PROTECTED]> writes:
> I'm trying to understand what happened here, and I have a theory.
The problem is the horrid misestimation of the selectivity of
"nursestation_key = 40":
-> Bitmap Index Scan on idx_visit_nursestation_key
(cost=0.00..69.35 rows=4956 width=0
On Wednesday May 17 2006 11:44 am, Ed L. wrote:
> On Wednesday May 17 2006 10:37 am, Ed L. wrote:
> > Can someone help me understand why the 8.1.2 query below is
> > using a seq scan instead of an index scan? All relevant
> > columns appear to be indexed and all tables vacuum analyzed.
> >
> >
> >
On Wednesday May 17 2006 10:37 am, Ed L. wrote:
> Can someone help me understand why the 8.1.2 query below is
> using a seq scan instead of an index scan? All relevant
> columns appear to be indexed and all tables vacuum analyzed.
>
>
> $ psql -c "explain analyze select * from visit inner join
> p
Ed L. wrote:
Can someone help me understand why the 8.1.2 query below is
using a seq scan instead of an index scan?
Because the planner thinks a sequential scan would be faster than an
index scan - in many situations, this is the case. See the FAQ:
http://www.postgresql.org/docs/faqs.FAQ
Can someone help me understand why the 8.1.2 query below is
using a seq scan instead of an index scan? All relevant
columns appear to be indexed and all tables vacuum analyzed.
$ psql -c "analyze verbose patient"
INFO: analyzing "public.patient"
INFO: "patient": scanned 3000 of 335
22 matches
Mail list logo
