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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance pgsql-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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-01 00:10:38 | Re: [SQL] 7.3 analyze & vacuum analyze problem |
Previous Message | Achilleus Mantzios | 2003-04-30 21:13:40 | Re: [SQL] 7.3 analyze & vacuum analyze problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-01 00:10:38 | Re: [SQL] 7.3 analyze & vacuum analyze problem |
Previous Message | Achilleus Mantzios | 2003-04-30 21:13:40 | Re: [SQL] 7.3 analyze & vacuum analyze problem |