Re: Relation extension scalability

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Relation extension scalability
Дата
Msg-id CAFiTN-t=wrVREMJp=h_6NGXrbKT89XP+aoAtjELH3TFwKQL3LA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Relation extension scalability  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Relation extension scalability
Re: Relation extension scalability
Список pgsql-hackers

On Tue, Mar 29, 2016 at 10:08 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
Yes, that makes sense.  One more point is that if the reason for v13 giving better performance is extra blocks (which we believe in certain cases can leak till the time Vacuum updates the FSM tree), do you think it makes sense to once test by increasing lockWaiters * 20 limit to may be lockWaiters * 25 or lockWaiters * 30.

I tested COPY 10000 record, by increasing the number of blocks just to find out why we are not as good as V13
 with extraBlocks = Min( lockWaiters * 40, 2048) and got below results..

COPY 10000
--------------------
Client  Patch(extraBlocks = Min( lockWaiters * 40, 2048))
--------           ---------
16 752
32 708

This proves that main reason of v13 being better is its adding extra blocks without control.
though v13 is better than these results, I think we can get that also by changing multiplier and max limit .

But I think we are ok with the max size as 4MB (512 blocks) right?.

Does this test make sense ?
 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: So, can we stop supporting Windows native now?
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.