On Tue, Mar 29, 2016 at 7:26 AM, Robert Haas <robertmh...@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().
>
I am attaching new version v17.
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.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
multi_extend_v17.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
