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 4 relations dropping is
> reasonable. In fact, this happens in a very special scenario .
> But when we analyzed this issue, we found the PG c
Robert Haas writes:
> Possibly, but it's not necessarily a bad idea to improve performance
> for people with crazy schemas.
It is if it introduces unmaintainable code. I see no way to collapse
multiple drop operations into one that's not going to be a Rube Goldberg
device. I'm especially unwill
On Thu, Feb 17, 2011 at 10:37 PM, Tom Lane wrote:
> Gan Jiadong 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 4 tables is
: 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 writes:
> we have PG 8.3.13 in our system. When running performance cases,
: 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 writes:
> we have PG 8.3.13 in our system. When running performance ca
Gan Jiadong 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 4 tables is a
cheap operation. Why do you have that many in the fir
