This can also be a shortcoming of pgAdmin. There have been a number of improvements for recent versions. Which one do you use? 1.14.2 is the current version (as of 2012-05-21).
Are queries from the command line interface psql
slow, too?
Apart from that, you need to keep vacuuming all your tables in the database, not just pg_tables
. I would strongly advice to enable the auto vacuuming daemon.
Also, pg_tables
is not relevant at all. It is a system view to implement the SQL standard information schema. The relevant system tables would be pg_namespace
, pg_class
, pg_attribute
and others. But it is pointless to target just one of them. For your kind of setup you need to be vacuuming the whole catalog. And it is very advisable to vacuum all of your database on a regular basis anyway. So, let me repeat: use autovacuum
.
For starters, you can run in a Debian shell:
vacuumdb -afz
reindexdb -a
reindexdb -s
The last line targets system tables for possible bloat of indexes in the catalog in particular. See man reindexdb
or the fine manual.
Finally, another option would be to upgrade to PostgreSQL 9.1. There have been a number of improvements for VACUUM
and ANALYZE
(among many others). In particular VACUUM FULL
has been rewritten for 9.0 and does a much better job now.
You need to enter the password of the database user, not the OS user. The "root password" is not applicable. Do you know the password of the database user postgres
?
Most systems are set up allowing peer authentication for local connections, meaning a system user can log into the database with a database user of the same name without password. localhost
is not a local connection. Its privileges are determined by host
entries in your pg_hba.conf
file.
Since you seem to be running Postgres and pgAdmin on the same server, I suggest you try a local connection without password. Quoting the pgAdmin manual:
On Unix based systems, the address field may be left blank to use the
default PostgreSQL Unix Domain Socket on the local machine, or be set
to an alternate path containing a PostgreSQL socket.
Bold emphasis mine.
Of course, you have to run pgAdmin as the system user postgres
for this to work.
This related answer on SO has a lot more details and links.
Best Answer
From this post:
But, from the comment to this post here, this method is sometimes unreliable. Use at your own risk! You might also be interested in this - it appears that PostgreSQL is finally going down the road of an Oracle wait interface.
If you'd care to file a feature request and post the link in a comment here (with @VĂ©race in the body), I'd be happy to file a "me-too".