Re: \d on database with a lot of tables is slow
От | Tom Lane |
---|---|
Тема | Re: \d on database with a lot of tables is slow |
Дата | |
Msg-id | 29525.1127861593@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: \d on database with a lot of tables is slow ("Jim C. Nasby" <jnasby@pervasive.com>) |
Ответы |
Re: \d on database with a lot of tables is slow
Re: \d on database with a lot of tables is slow |
Список | pgsql-hackers |
"Jim C. Nasby" <jnasby@pervasive.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
В списке pgsql-hackers по дате отправления: