\d very, very, very slow
I'm seeing very, very slow response to \d <tablename> - around 15-20
seconds on an otherwise idle Netra.
PostgreSQL 7.2.1 on sparc-sun-solaris2.8, compiled by cc -xarch=v9 -Xa
Running psql -E shows that \d is issuing 4 queries. Picking one at
random at running it through explain analyze shows three nested
seqscans and a few joins, taking 6500ms.
(Running the same query on a Linux box running Postgresql 7.2 with the
same schema and similar postgresql.conf shows the same query plan,
taking 80ms.)
So is 15-20 seconds for \d unusual? If so, where should I start looking
to see what's broken?
Any thoughts appreciated.
Cheers,
Steve
Steve Atkins <steve@blighty.com> writes:
I'm using postgres for a long-running application[1], where I'd really
rather the application daemons don't have any access as the postgres
user. As the schema doesn't change is it safe to analyze the system
tables as the postgres user once at installation time or should I
be doing that as part of the normal cronjobbed maintenance?
If you're not doing any schema changes then the ANALYZE stats for the
system tables shouldn't need updates, probably. On the other hand,
I'm not sure what it buys you to avoid it. Running "vacuum analyze"
as the postgres user from a cron job is standard practice in my book.
regards, tom lane
Import Notes
Reply to msg id not found: 20020803234847.A30134@blighty.com