Re: \d on database with a lot of tables is slow

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Hannu Krosing <hannu(at)skype(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: \d on database with a lot of tables is slow
Date: 2005-09-27 22:53:13
Message-ID: 29525.1127861593@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> On Mon, Sep 26, 2005 at 03:00:44PM -0400, Tom Lane wrote:
>> It's presumably mostly in the pg_table_is_visible() calls. Not sure if
>> we can do much to speed those up, but: how many schemas in your search
>> path? What's the distribution of pg_class entries among the schemas?

> db=# show search_path;
> decibel, pg_sysviews, information_schema, rrs, public

> db=# select schema_name, count(*) from pg_user_tables group by schema_name;
> public | 764
> ledger | 6
> state | 2
> _track_replica | 10
> repair | 3
> summarized | 586
> orders | 512
> snapshot | 1012
> acl | 10

Hmm, so lots and lots of tables that aren't visible at all ... that's
definitely the slowest case for pg_table_is_visible. I'll think about
whether we can improve it.

> Also, do you have any idea on the 'Did not find relation named
> "table-thats-there"' error? table-thats-there isn't a temp table, and I don't
> believe they're even using temp tables, so I don't think that's the issue.

Uh, what's the exact error message again? (If it's a backend message,
the verbose form would be useful.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-09-27 22:57:03 Re: Vacuum questions...
Previous Message Tom Lane 2005-09-27 22:46:55 Proposed patch for sequence-renaming problems