| From: | Michael Shapiro <mshapiro(at)ncsa(dot)edu> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: PgAdmin startup query VERY slow |
| Date: | 2004-01-06 21:31:29 |
| Message-ID: | 5.2.0.9.2.20040106152859.02a17ea8@pop.ncsa.uiuc.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
That seemed to fix it. What does VACUUM ANALYZE do that VACUUM FULL does
not? What causes a database to need vacuuming?
At 01:01 PM 1/6/2004 -0800, Josh Berkus wrote:
>Michael,
>
> > With a particular database, PgAdmin3 takes a very long time to connect
> to a
> > database. this is not a general problem with PgAdmin, but only with one
> > database out of many. Other databases do not have the problem. And only
> > with one particular server. The exact same database on a different server
> > does not have the problem.
>
>Have you run VACUUM ANALYZE *as the superuser* on the faulty server
>recently?
> >From the look of the explain, PG is grossly underestimating the number of
>items in the pg_trigger and pg_depend tables, and thus choosing an
>inappropriate nested loop execution.
>
>--
>-Josh Berkus
> Aglio Database Solutions
> San Francisco
---
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | D'Arcy J.M. Cain | 2004-01-06 22:57:05 | Re: Select max(foo) and select count(*) optimization |
| Previous Message | Josh Berkus | 2004-01-06 21:17:30 | Re: PgAdmin startup query VERY slow |