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 can be 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: ga...@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:t...@sss.pgh.pa.us] 发送时间: 2011年2月18日 11:37 收件人: Gan Jiadong 抄送: pgsql-hackers@postgresql.org; liyue...@huawei.com; yaoy...@huawei.com; liuxin...@huawei.com; tianweng...@huawei.com 主题: Re: [HACKERS] About the performance of startup after dropping many tables Gan Jiadong <ga...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
