Re: Suboptimal plan choice problem with 8.3RC2 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Suboptimal plan choice problem with 8.3RC2
Date
Msg-id 20080122205256.GL10897@alvh.no-ip.org
Whole thread Raw
In response to Re: Suboptimal plan choice problem with 8.3RC2  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Responses Re: Suboptimal plan choice problem with 8.3RC2
List pgsql-hackers
Guillaume Smet escribió:
> On Jan 22, 2008 8:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> > I'd expect 8.1 to make about the same estimate given the same stats,
> > so I think it's not looking at the same stats.
> 
> Yep, the statistics were the problem, sorry for the noise. The query
> performs in 50ms after an ANALYZE so far better than with 8.1.
> 
> The 8.3RC2 box is using the default configuration of autovacuum
> though. Shouldn't it take care of keeping the statistics up to date?
> That's what I thought from what I've read on autovacuum so far (it's
> the first time I use it in "production" though, it was a manual
> process until now) - and that's why I didn't check it. Or should we
> still run the first ANALYZE manually?

No, autovacuum should have taken care of it.  I would be interesting in
knowing why it didn't.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Warren Turkal
Date:
Subject: [PATCH] Add TimeOffset and DateOffset typedefs
Next
From: Warren Turkal
Date:
Subject: Fixed patch for timestamp refactor effort