Re: bug with vacuum analyze?

From: Neil Conway <neilc(at)samurai(dot)com>
To: "Trever L(dot) Adams" <tadams-lists(at)myrealbox(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: bug with vacuum analyze?
Date: 2003-03-12 17:57:47
Message-ID: 1047491867.359.168.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, 2003-03-10 at 13:29, Trever L. Adams wrote:
> If I never do a vacuum analyze, it takes between 8-11 (high spikes
> around 23) seconds most of the time for this first page to load. If I
> do vacuum, nothing seems to change. If I do a vacuum analyze, the
> minimum load time is between 41-44 seconds. Higher system loads,
> instead of adding 4-10 seconds, easily double the number up beyond 80
> seconds. Yes, each of these tables have at least one index (the most
> indexes I believe are 4). Those with multiple, I believe, all have a
> primary index key.

> Is this a bug, known or otherwise, are their workarounds besides don't
> do it?

It doesn't look like a bug in VACUUM -- more likely, running VACUUM
ANALYZE causes the optimizer to use a different query plan, which
happens to perform much worse for the queries you're running.

(In general, ANALYZE should improve query plans, but it seems that by
chance the bogus plan the optimizer chooses without stats is actually
better than the choice it makes when more informed).

Can you post the relevant query, the schemas of any involved relations
and the output of EXPLAIN ANALYZE for the query both before and after
running VACUUM ANALYZE?

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Evgeny Duzhakow 2003-03-12 20:15:08 create table permissions bug for 7.3.2
Previous Message Tom Lane 2003-03-12 17:18:40 Re: Aliased SubSelect in HAVING clause bug -- in progress?