Hi,
Thanks for your reply. Of course, we will think about whether 40000 relations dropping is
reasonable. In fact, this happens in a very special scenario . But when we analyzed this issue, we found the PG code
canbe rewritten to
achieve better performance. Or we can say the arithmetic of this part is not
good enough. For example, by doing the refactoring as we done, the startup time can be
reduced from 3 minutes to 8 seconds, It is quite a great improvement,
especially for the systems with low TTR (time to recovery) requirement.
There is any problem or risk to change this part of code as we suggested?
Thank you.
Best reguards,
甘嘉栋(Gan Jiadong)
E-MAIL: ganjd@huawei.com
Tel：+86-755-289720578
****************************************************************************
*****************************
This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
****************************************************************************
*****************************
-----邮件原件-----
发件人: Tom Lane [mailto:tgl@sss.pgh.pa.us]
发送时间: 2011年2月18日 11:37
收件人: Gan Jiadong
抄送: pgsql-hackers@postgresql.org; liyuesen@huawei.com; yaoyiyu@huawei.com;
liuxingyu@huawei.com; tianwengang@huawei.com
主题: Re: [HACKERS] About the performance of startup after dropping many
tables
Gan Jiadong <ganjd@huawei.com> writes:
> we have PG 8.3.13 in our system. When running performance cases, we find
the
> startup recovery cost about 3 minutes. It is too long in our system.
Maybe you should rethink the assumption that dropping 40000 tables is a
cheap operation. Why do you have that many in the first place, let
alone that many that you drop and recreate frequently? Almost
certainly, you need a better-conceived schema.
regards, tom lane
