Re: 答复: response time is very long in PG9.5.5 using psql or jdbc

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 答复: response time is very long in PG9.5.5 using psql or jdbc
Дата
Msg-id 30157.1518548280@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 答复: response time is very long in PG9.5.5 using psql or jdbc  (石勇虎 <SHIYONGHU651@pingan.com.cn>)
Ответы Re: 答复: response time is very longin PG9.5.5 using psql or jdbc
Re: response time is very long in PG9.5.5 using psql or jdbc
Список pgsql-bugs
=?gb2312?B?yq/Twrui?= <SHIYONGHU651@pingan.com.cn> writes:
> Yes,we have more than 500 thousand of objects,and the total size of the database is almost 10TB.Just as you said,we
mayneed to reduce the objects number,or you have any better solution? 

Hmph.  I tried creating 500000 tables in a test database, and couldn't
detect any obvious performance problem in session startup.  So there's
something very odd about your results.  You might try looking at the
sizes of the system catalogs, e.g like
    select pg_size_pretty(pg_total_relation_size('pg_attribute'));
(In my test database, pg_class is about 80MB and pg_attribute about
800MB.)

> And I also have a question that if the backend's internal caches of catalog is shared with other users or sessions?if
thepgbouncer is usefull? 

pgbouncer or some other connection pooler would help, yes.  But I don't
think the underlying performance ought to be this bad to begin with.

            regards, tom lane


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15060: Row in table not found when using pg function in an expression
Следующее
От: Andres Freund
Дата:
Сообщение: Re: 答复: response time is very longin PG9.5.5 using psql or jdbc