Re: [Patch] Optimize dropping of relation buffers using dlist
От | Amit Kapila |
---|---|
Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | CAA4eK1LgaTSt+=EOf4x=r0Ce0-rNA=o47nGmFp2_Ds_CNgwXFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] Optimize dropping of relation buffers using dlist (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: [Patch] Optimize dropping of relation buffers using dlist
|
Список | pgsql-hackers |
On Fri, Jan 8, 2021 at 7:03 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Thu, 7 Jan 2021 09:25:22 +0000, "k.jamison@fujitsu.com" <k.jamison@fujitsu.com> wrote in: > > > Thanks for the detailed tests. NBuffers/32 seems like an appropriate > > > value for the threshold based on these results. I would like to > > > slightly modify part of the commit message in the first patch as below > > > [1], otherwise, I am fine with the changes. Unless you or anyone else > > > has any more comments, I am planning to push the 0001 and 0002 > > > sometime next week. > > > > > > [1] > > > "The recovery path of DropRelFileNodeBuffers() is optimized so that > > > scanning of the whole buffer pool can be avoided when the number of > > > blocks to be truncated in a relation is below a certain threshold. For > > > such cases, we find the buffers by doing lookups in BufMapping table. > > > This improves the performance by more than 100 times in many cases > > > when several small tables (tested with 1000 relations) are truncated > > > and where the server is configured with a large value of shared > > > buffers (greater than 100GB)." > > > > Thank you for taking a look at the results of the tests. And it's also > > consistent with the results from Tang too. > > The commit message LGTM. > > +1. > I have pushed the 0001. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: