From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Gan Jiadong <ganjd(at)huawei(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, liyuesen <liyuesen(at)huawei(dot)com>, yaoyiyu <yaoyiyu(at)huawei(dot)com>, liuxingyu <liuxingyu(at)huawei(dot)com>, tianwengang <tianwengang(at)huawei(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
Subject: | Re: About the performance of startup after dropping many tables |
Date: | 2011-09-07 19:20:10 |
Message-ID: | 1315422909-sup-6411@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Gan Jiadong's message of vie feb 18 03:42:02 -0300 2011:
> 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?
The only way to know would be to show the changes. If you were to
submit the patch, and assuming we agree on the design and
implementation, we could even consider including it (or, more likely,
some derivate of it).
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-09-07 19:23:25 | Re: custom variables and PGC_SUSET issue |
Previous Message | Robert Haas | 2011-09-07 19:18:00 | Re: custom variables and PGC_SUSET issue |