Skip site navigation (1) Skip section navigation (2)

Re: [SQL] 7.3 analyze & vacuum analyze problem

From: "Ron Mayer" <ron(at)intervideo(dot)com>
To: <josh(at)agliodbs(dot)com>,"Achilleus Mantzios" <achill(at)matrix(dot)gatewaynet(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [SQL] 7.3 analyze & vacuum analyze problem
Date: 2003-04-30 22:16:58
Message-ID: POEDIPIPKGJJLDNIEMBEMEOACKAA.ron@intervideo.com (view raw or flat)
Thread:
Lists: pgsql-performancepgsql-sql
Josh wrote...
> Achilleus,
> 
> > I am afraid it is not so simple.
> > What i (unsuccessfully) implied is that 
> > dynacom=# VACUUM ANALYZE status ;
> > VACUUM
> > dynacom=# ANALYZE status ;
> > ANALYZE
> > dynacom=#
> >
> > [is enuf to damage the performance.]
> 
> You're right, that is mysterious.   If you don't get a response from one of 
> the major developers on this forum, I suggest that you post those EXPLAIN 
> results to PGSQL-BUGS.

I had the same problem a while back.

http://archives.postgresql.org/pgsql-bugs/2002-08/msg00015.php
http://archives.postgresql.org/pgsql-bugs/2002-08/msg00018.php
http://archives.postgresql.org/pgsql-bugs/2002-08/msg00018.php

Short summary: Later in the thread Tom explained my problem as free 
space not being evenly distributed across the table so ANALYZE's 
sampling gave skewed results.  In my case, "pgstatuple" was a 
good tool for diagnosing the problem, "vacuum full" fixed my table
and a much larger fsm_* would have probably prevented it.


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2003-05-01 00:10:38
Subject: Re: [SQL] 7.3 analyze & vacuum analyze problem
Previous:From: Achilleus MantziosDate: 2003-04-30 21:13:40
Subject: Re: [SQL] 7.3 analyze & vacuum analyze problem

pgsql-sql by date

Next:From: Tom LaneDate: 2003-05-01 00:10:38
Subject: Re: [SQL] 7.3 analyze & vacuum analyze problem
Previous:From: Achilleus MantziosDate: 2003-04-30 21:13:40
Subject: Re: [SQL] 7.3 analyze & vacuum analyze problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group