Re: Relation extension scalability
| От | Dilip Kumar |
|---|---|
| Тема | Re: Relation extension scalability |
| Дата | |
| Msg-id | CAFiTN-sxgazkW_xmXZ8OE838DV-_ELCni291sCenTDKfzXYiYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Relation extension scalability (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Relation extension scalability
|
| Список | pgsql-hackers |
On Tue, Mar 29, 2016 at 7:26 AM, Robert Haas <robertmhaas@gmail.com> wrote:
Well, it's less important in that case, but I think it's still worth
doing. Some people are going to do just plain GetPageWithFreeSpace().
Its like this...
In RelationAddExtraBlocks
{
-- Add Block one by one to FSM.
-- Update FSM tree all the way to root
}
In RelationGetBufferForTuple
--- Same as v14, search the FSM tree from root. GetPageWithFreeSpace
Summary:
--------------
1. By Adding block to FSM tree one by one it solves the problem of unused blocks in V14.
2. It Update the FSM tree all they up to root, so anybody search from root can get the block.
3. It also search the block from root, so it don't have problem like v15 has(Exactly identifying which two FSM page to search).
4. This solves the performance problem of V14 by some optimizations in logic of updating FSM tree till root.
Performance Data:
--------------------------
Client base v17
-------- -------- --------
1 117 120
2 111 123
4 51 124
8 43 135
16 40 145
32 35 144
64 -- 140
Client base v17
------- ------- ------
1 118 117
2 217 220
4 210 379
8 166 574
16 145 594
32 124 599
64 ---- 609
Notes:
---------
If I do some change in this patch in strategy of searching the block, performance remains almost the same.
1. Like search in two block like v15 or v17 does.
2. Search first using target block and if don't get then search from top.
Вложения
В списке pgsql-hackers по дате отправления: