Re: [Patch] Optimize dropping of relation buffers using dlist

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [Patch] Optimize dropping of relation buffers using dlist
Дата
Msg-id CAA4eK1K2=KL9x7UTAFQ-YgZX0xFHKQB3ayru-tcaqCAVmxS0wg@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [Patch] Optimize dropping of relation buffers using dlist  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
Ответы RE: [Patch] Optimize dropping of relation buffers using dlist  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
Список pgsql-hackers
On Wed, Dec 30, 2020 at 11:28 AM Tang, Haiying
<tanghy.fnst@cn.fujitsu.com> wrote:
>
> Hi Amit,
>
> In last
mail(https://www.postgresql.org/message-id/66851e198f6b41eda59e6257182564b6%40G08CNEXMBPEKD05.g08.fujitsu.local),
> I've sent you the performance test results(run only 1 time) on single table. Here is my the retested results(average
by15 times) which I think is more accurate.
 
>
> In terms of 20G and 100G, the optimization on 100G is linear, but 20G is nonlinear(also include test results on
sharedbuffers of 50G/60G), so it's a little difficult to decide the threshold from the two for me.
 
> If just consider 100G, I think NBuffers/32 is the optimized max relation size. But I don't know how to judge for 20G.
Ifyou have any suggestion, kindly let me know.
 
>

Considering these results NBuffers/64 seems a good threshold as beyond
that there is no big advantage. BTW, it is not clear why the advantage
for single table is not as big as multiple tables with the Truncate
command. Can you share your exact test steps for any one of the tests?
Also, did you change autovacumm = off for these tests, if not then the
results might not be reliable because before you run the test via
Vacuum command autovacuum would have done that work?

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Parallel Inserts in CREATE TABLE AS
Следующее
От: vignesh C
Дата:
Сообщение: Re: Parallel Inserts in CREATE TABLE AS